Clear enough.
Let's focusing on your example as it is far not so bad solution.
Your example is better because of port/ip sets automatically and we don't need to care about the shutdown.
But how to make it work?
- it doesn't work in my case because “Attribute Create” node create empty ‘trackaddress’ parm early then tracker is started.
- “Dynamic” generation is helping to create attrs in the right time but ROPFetch is saying: “When not generating static items, batch mode can only be used when the ”Full Range for Upsteam Items“ is selected”
- “Python Script” node still doing it after ‘onGenerate’ callback
ROP Fetch: Distribution options as a separate node
6954 32 3- Ostap
- Member
- 209 posts
- Joined: Nov. 2010
- Offline
- tpetrick
- Staff
- 585 posts
- Joined: May 2014
- Offline
I've recreated/fixed the example. You're right that the attrib create doesn't work - when I was testing that I must have had something cached so it appeared to work, or I uploaded the wrong file.
The working solution isn't very clean, though. It relies on the fact that the rop fetch work items have access to the input lists, and extracts the tracker information using pdginput(..) at cook time. You can see that on the /obj/AutoDopNetwork/DISTRIBUTE_fliptank_CONTROLS node.
The way the built-in distributed sim handles this is it copies the tracker information onto the slice work items immediately before cooking, so the correct tracker port/ip are available and passed to the sim jobs. It would be a simple change on our end to add an option to do that for externally created trackers as well. For example, a check box on the rop fetch/rop geometry to tell the rop fetch to use a manually created, upstream tracker.
The working solution isn't very clean, though. It relies on the fact that the rop fetch work items have access to the input lists, and extracts the tracker information using pdginput(..) at cook time. You can see that on the /obj/AutoDopNetwork/DISTRIBUTE_fliptank_CONTROLS node.
The way the built-in distributed sim handles this is it copies the tracker information onto the slice work items immediately before cooking, so the correct tracker port/ip are available and passed to the sim jobs. It would be a simple change on our end to add an option to do that for externally created trackers as well. For example, a check box on the rop fetch/rop geometry to tell the rop fetch to use a manually created, upstream tracker.
- Ostap
- Member
- 209 posts
- Joined: Nov. 2010
- Offline
- chrisgreb
- Member
- 603 posts
- Joined: Sept. 2016
- Offline
The example executes sharedserver.py with the genericgenerator. This uses the result data api which is in pdgcmd.py. The function is called reportResultData. Jobs generally report result data back to pdg using that api, which is using XMLRPC under the hood.
In theory any job could do that as long as they were able to formulate the correct XMLRPC client call (from C++ or whatever)
In theory any job could do that as long as they were able to formulate the correct XMLRPC client call (from C++ or whatever)
Edited by chrisgreb - June 14, 2019 11:02:09
- Ostap
- Member
- 209 posts
- Joined: Nov. 2010
- Offline
- Ostap
- Member
- 209 posts
- Joined: Nov. 2010
- Offline
I found another problem regarding multiple distributed simulations.
When I use multiple PDG sharedserver (at the same time) for tracker purpose (the same as your example but with adding the second simulation) then second simulation is producing not correct data (FLIP noise).
Looks like it is not an issue of the trackers itself because when I use two predefined trackers then everything is fine.
When I use multiple PDG sharedserver (at the same time) for tracker purpose (the same as your example but with adding the second simulation) then second simulation is producing not correct data (FLIP noise).
Looks like it is not an issue of the trackers itself because when I use two predefined trackers then everything is fine.
Edited by Ostap - June 19, 2019 07:08:35
- Ostap
- Member
- 209 posts
- Joined: Nov. 2010
- Offline
- chrisgreb
- Member
- 603 posts
- Joined: Sept. 2016
- Offline
- Ostap
- Member
- 209 posts
- Joined: Nov. 2010
- Offline
- Ostap
- Member
- 209 posts
- Joined: Nov. 2010
- Offline
- tpetrick
- Staff
- 585 posts
- Joined: May 2014
- Offline
- Ostap
- Member
- 209 posts
- Joined: Nov. 2010
- Offline
- tpetrick
- Staff
- 585 posts
- Joined: May 2014
- Offline
-
- Quick Links