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.