Hi Jerome,
in my opinion it is not bug nor indesirable feature. O.load should load
everything what is saved, including O.tags. I think there would be plenty
of situations where you define O.tags, save it and after load you want to
have them. As an extreme, one may complain that after O.load, the bodies
are loaded from previous simulation :-)
what about this as a solution (readParamsFromTable after O.load)?
###### second.py ########################################
O.load('first.yade')
readParamsFromTable(secondParam = 'toto')
from yade.params.table import *
print 'In second.py at the end, O.tags[params] =', O.tags['params']
#######################################################
cheers
Jan
2016-06-24 18:27 GMT+02:00 Jérôme Duriez <jerome.dur...@ucalgary.ca>:
> ** Attachment added: "second.table"
>
> https://bugs.launchpad.net/yade/+bug/1596021/+attachment/4689856/+files/second.table
>
> --
> You received this bug notification because you are a member of Yade
> developers, which is subscribed to Yade.
> https://bugs.launchpad.net/bugs/1596021
>
> Title:
> O.tags['params'] for 2 batchs and 1 save
>
> Status in Yade:
> New
>
> Bug description:
> Hello,
>
> I've faced some issue for batch simulation. I have a batch simulation
> that loads a .yade save from a previous simulation that was also
> launched in batch mode.
>
> The two batch-mode simulations consider different parameters in their
> .table. And in the second simulation, O.tags['params'] refers to the
> parameters of the first batch-mode simulation, while I would like it
> refers to the parameters of the current simulation..
>
> I'm attaching example scripts "first.py" and "second.py", together
> with their "first.table" and "second.table" to illustrate. "first.py"
> will generate a .yade that will be used by "second.py". During the
> batch execution of "second.py", O.tags['params'] refers to first.table
> instead of second.table.
>
> It turns out the O.load erases the right O.tags['params']
>
> Do we agree it is a bug or, at least, an indesirable feature ? Would
> it be possible to not save O.tags['params'] in .yade files ?
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/yade/+bug/1596021/+subscriptions
>
> _______________________________________________
> Mailing list: https://launchpad.net/~yade-dev
> Post to : yade-dev@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~yade-dev
> More help : https://help.launchpad.net/ListHelp
>
--
You received this bug notification because you are a member of Yade
developers, which is subscribed to Yade.
https://bugs.launchpad.net/bugs/1596021
Title:
O.tags['params'] for 2 batchs and 1 save
Status in Yade:
New
Bug description:
Hello,
I've faced some issue for batch simulation. I have a batch simulation
that loads a .yade save from a previous simulation that was also
launched in batch mode.
The two batch-mode simulations consider different parameters in their
.table. And in the second simulation, O.tags['params'] refers to the
parameters of the first batch-mode simulation, while I would like it
refers to the parameters of the current simulation..
I'm attaching example scripts "first.py" and "second.py", together
with their "first.table" and "second.table" to illustrate. "first.py"
will generate a .yade that will be used by "second.py". During the
batch execution of "second.py", O.tags['params'] refers to first.table
instead of second.table.
It turns out the O.load erases the right O.tags['params']
Do we agree it is a bug or, at least, an indesirable feature ? Would
it be possible to not save O.tags['params'] in .yade files ?
To manage notifications about this bug go to:
https://bugs.launchpad.net/yade/+bug/1596021/+subscriptions
_______________________________________________
Mailing list: https://launchpad.net/~yade-dev
Post to : yade-dev@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yade-dev
More help : https://help.launchpad.net/ListHelp
