Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Pleque Structure #36

Open
Mateasek opened this issue Sep 26, 2018 · 0 comments
Open

Pleque Structure #36

Mateasek opened this issue Sep 26, 2018 · 0 comments
Assignees

Comments

@Mateasek
Copy link
Contributor

Mateasek commented Sep 26, 2018

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?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

5 participants