getShifted/getUnshifted methods for BoutOutputs - #1175
Conversation
|
|
||
|
|
||
| :ivar attributes: dictionary of attributes from the first DataFile | ||
| :ivar evolvingVariables: list of time-evolving variables |
There was a problem hiding this comment.
Please could you put these in numpydoc style? These can go under an Attributes section (see link)
If the data files have attributes, read them into a dictionary, BoutOutputs.attributes
BoutOutputs.evolvingVariables() was only a getter function for a private instance attribute. This is not good Python style: https://www.python-course.eu/python3_properties.php It is better to use a public instance attribute, then if getter/setter type functionality is needed later, use @Property and, e.g., @evolvingVariables.setter decorators. This allows for example checks to be done when setting an attribute, but still allows the class user to access like a variable instead of a function. For example: >> data = BoutOutputs() >> print(data.evolvingVariables) ['n', 'T'] instead of: >> data = BoutOutputs() >> print(data.evolvingVariables()) ['n', 'T']
Store as a string in the Field3D and write as an attribute in output files. The default is set by the ParallelTransform but changed to 'fieldaligned' by 'toFieldAligned()' and changed back by 'fromFieldAligned()'
In the BoutOutputs methods getShifted() and getUnshifted(), check the variable attribute 'coordinate_system' so getShifted() only transforms orthogonal->field-aligned (null op for field-aligned variable) and getUnshifted only transforms field-aligned->orthogonal (null op for orthogonal variable).
97ac700 to
2f7b126
Compare
|
@ZedThree thanks for the comments! The parts using file attributes to read options I should never have put in here. They were meant to go with another project which is incomplete anyway. Sorry! The support for file attributes was indeed broken, but I've fixed and tested it now. I think it may be useful in future. To allow getShifted/getUnshifted to do the right thing automatically, I've added another attribute to keep track of whether Field3Ds are in orthogonal or field-aligned coordinates. It required some changes to the BOUT++ code as well, so suggestions on a simpler way are welcome, but what I've added seems useful anyway. Don't know if we're ever likely to handle fields on a mix of orthogonal and field-aligned coordinates, but if we do there's some support for keeping track of it. Possibly coordinate_system should be an enum like CELL_LOC rather than a string? |
Avoids segfault if fieldmesh*==nullptr.
Options are used in setParallelTransform, so to use default options need to initialize something.
Initialize ParallelTransform in Mesh constructor, so it is almost always available. Initialize Field3Ds whose mesh has no ParallelTransform with coordinate_system="none" so they can be created to be used in initializing the ParallelTransform.
9d54456 to
baa1db8
Compare
This ensures that coordinate_system gets set when the field is initialized, not just when the constructor is called. This is important for 'old-style' simulations where global Field3Ds are used as variables, since their constructors are called before the mesh or parallel-transform are initialized.
Also check that lhs.getCoordinateSystem()==rhs.getCoordinateSystem() for binary operators.
Creating the FCITransform requires nx/ny/nz to be set in the mesh, so cannot call setParallelTransform() in the Mesh constructor, since it is called before these are initialized.
The method now does not set the parallel transform if needed, because the parallel transform is set in the constructor of BoutMesh, etc.
|
This PR would resolve #46. |
|
This PR should be re-written to use the |
|
To resolve #46, the Python code in this PR could be modified easily to recognise the |
|
Ok, closing as xBOUT replaces this functionality |
2 participants
Add methods to BoutOutputs class to shift fields orthogonal->field-aligned or the reverse.
Make 'evolvingVariables' a member variable rather than a method.
Add support to DataFile for file-level attributes.