I'm trying to solve two problems consecutively in the same program. Each problem defines its own field and variables. Specifically, I do this for testing (same problem creation and operation code run consecutively with different parameters), just for the context.
It fails when the second problem defines its field:
ValueError: order 0 already used!
which means that somewhere, there's a global mapping of numbers to variables which I need to clean.
I don't know how to do it, and if there are other such global states that need to be cleaned. So my question is whether there's some "nuke everything" function, or a checklist of things to clean, or some other way to do it?
My current workaround is to stick each run under a different process using the multiprocessing module. This works but I hope there's a less cumbersome way.
Thanks, Yosef Meller.
Hi Yosef,
On 5/18/23 15:51, Yosef Meller wrote:
I'm trying to solve two problems consecutively in the same program. Each problem defines its own field and variables. Specifically, I do this for testing (same problem creation and operation code run consecutively with different parameters), just for the context.
You are using the imperative API, right? (*)
How do you construct the problems - is copying involved?
It fails when the second problem defines its field:
ValueError: order 0 already used!which means that somewhere, there's a global mapping of numbers to variables which I need to clean.
Yes, each Variable checks class attributes _orders and _count.
I don't know how to do it, and if there are other such global states that need to be cleaned. So my question is whether there's some "nuke everything" function, or a checklist of things to clean, or some other way to do it?
The global ordering can be cleared by calling Variable.reset(), see sfepy/discrete/variables.py.
(*) BTW. Variables.from_conf() calls Variable.reset(), so constructing the problems in a declarative way should work.
My current workaround is to stick each run under a different process using the multiprocessing module. This works but I hope there's a less cumbersome way.
You can copy the variables, loop over them with .iter_state() and call .reset() manually - a bit less cumbersome, but not ideal. Let us know if that helps.
I will think how to get rid of the class attributes, although I am not sure how much code depends on that. I cannot recall why the ordering information is not in the Variables class, but there must have been a reason... Probably early checking, prior to putting the variables into Variables.
r.
Hi,
On Thu, May 18, 2023 at 5:21 PM Robert Cimrman <cimrman3@ntc.zcu.cz> wrote:
Hi Yosef,
On 5/18/23 15:51, Yosef Meller wrote:
I'm trying to solve two problems consecutively in the same program. Each problem defines its own field and variables. Specifically, I do this for testing (same problem creation and operation code run consecutively with different parameters), just for the context.
You are using the imperative API, right? (*)
Right. I know I'm a minority but at least it gets some testing, right?
How do you construct the problems - is copying involved?
No, just construction from scratch.
It fails when the second problem defines its field:
ValueError: order 0 already used!which means that somewhere, there's a global mapping of numbers to variables which I need to clean.Yes, each Variable checks class attributes _orders and _count. [snip]
You can copy the variables, loop over them with .iter_state() and call .reset() manually - a bit less cumbersome, but not ideal. Let us know if that helps.
using reset() on each variable through a class destructor was ok, although it would be preferable not to have to do it.
I will think how to get rid of the class attributes, although I am not sure how much code depends on that. I cannot recall why the ordering information is not in the Variables class, but there must have been a reason... Probably early checking, prior to putting the variables into Variables.
Looks to me like the attempt to assign order automatically is what necessitates the static attributes. I'd put it in the Field instance so that at least it goes away with the field, but a general Variable doesn't get a Field like FieldVariable.
On 5/21/23 13:41, Yosef Meller wrote:
Hi,
On Thu, May 18, 2023 at 5:21 PM Robert Cimrman <cimrman3@ntc.zcu.cz> wrote:
Hi Yosef,
On 5/18/23 15:51, Yosef Meller wrote:
I'm trying to solve two problems consecutively in the same program. Each problem defines its own field and variables. Specifically, I do this for testing (same problem creation and operation code run consecutively with different parameters), just for the context.
You are using the imperative API, right? (*)
Right. I know I'm a minority but at least it gets some testing, right?
Yes, testing it properly in previously unused scenarios is good.
FWIW I am also often using the imperative API, or even more often a combination. One example of that is in assemble_matrices() of [1]. And constructing equations term by term is sort of tedious, so even in purely imperative scripts I tend to use Equations.from_conf().
[1] https://sfepy.org/doc/examples/linear_elasticity-dispersion_analysis.html
How do you construct the problems - is copying involved? No, just construction from scratch.
OK. I was wondering what data are shared.
It fails when the second problem defines its field:
ValueError: order 0 already used!which means that somewhere, there's a global mapping of numbers to variables which I need to clean.Yes, each Variable checks class attributes _orders and _count. [snip]
You can copy the variables, loop over them with .iter_state() and call .reset() manually - a bit less cumbersome, but not ideal. Let us know if that helps.
using reset() on each variable through a class destructor was ok, although it would be preferable not to have to do it.
Yes.
I will think how to get rid of the class attributes, although I am not sure how much code depends on that. I cannot recall why the ordering information is not in the Variables class, but there must have been a reason... Probably early checking, prior to putting the variables into Variables.
Looks to me like the attempt to assign order automatically is what necessitates the static attributes. I'd put it in the Field instance so that at least it goes away with the field, but a general Variable doesn't get a Field like FieldVariable.
IIRC the automatic order checks are a remnant from times when lots of things were computed already during a variable construction, so it was worth to fail early. Nowadays it is not so.
I will try to get rid of it, as it is another weird internal state that can lead to strange erros. It is not needed in standalone variables, and once unknowns are collected into Variables, the order attributes can be checked.
r.
participants (2)
-
Robert Cimrman -
Yosef Meller