You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
While preparing export of FluxFunction objects to omas I realised this is one way how to get equilibrium data from a coordinate object is for example this:
coords._eq.tor_flux(coords)
I am not sure if the possibility or need to do this is a good Idea. I am also afraid it could lead to growing ambiguity, cyclic referencing and confusion in the module and it's using as it grows.
Please correct me if I'm wrong.
Equilibriumclass functions work with coordinates objects, e.g.:
The equilibrium object has to be passed to the coordinates upon creation and is saved as a property : code
Isn't this kind of a cycle which could in future fire back? Another disadvantage is (as I've already mentioned) is that the user has to be either keeping both equilibrium and coordinates objects to get
some equilibrium value for the coordinates (although the equilibrium is saved in coordinates), e.g.:
equi = Equilibrium(...) coords = equi.coordinates(...) equi.tor_flux(coords)
`
or keep using this:
I might be wrong disliking this and maybe this way is the correct way. But I think the structure of the whole module should be changed to avoid this. One possibility to solve this could could be by using inheritance by making the coordinates class child class of the equilibrium. What do you think?
The text was updated successfully, but these errors were encountered:
While preparing export of FluxFunction objects to omas I realised this is one way how to get equilibrium data from a coordinate object is for example this:
coords._eq.tor_flux(coords)
I am not sure if the possibility or need to do this is a good Idea. I am also afraid it could lead to growing ambiguity, cyclic referencing and confusion in the module and it's using as it grows.
Please correct me if I'm wrong.
Equilibriumclass functions work with coordinates objects, e.g.:
code
The equilibrium object has to be passed to the coordinates upon creation and is saved as a property :
code
Isn't this kind of a cycle which could in future fire back? Another disadvantage is (as I've already mentioned) is that the user has to be either keeping both equilibrium and coordinates objects to get
some equilibrium value for the coordinates (although the equilibrium is saved in coordinates), e.g.:
equi = Equilibrium(...)
coords = equi.coordinates(...)
equi.tor_flux(coords)
`
or keep using this:
equi = Equilibrium(...)
coords = equi.coordinates(...)
coords._equi.tor_flux(coords)
`
I might be wrong disliking this and maybe this way is the correct way. But I think the structure of the whole module should be changed to avoid this. One possibility to solve this could could be by using inheritance by making the coordinates class child class of the equilibrium. What do you think?
The text was updated successfully, but these errors were encountered: