Ignore FieldPerps when loading datasets #37
Conversation
Codecov Report
@@ Coverage Diff @@
## master #37 +/- ##
==========================================
- Coverage 51.85% 51.69% -0.16%
==========================================
Files 8 8
Lines 351 354 +3
Branches 63 65 +2
==========================================
+ Hits 182 183 +1
- Misses 153 154 +1
- Partials 16 17 +1
Continue to review full report at Codecov.
|
There was a problem hiding this comment.
I can't say I really understand how FieldPerps work. Is this related to boutproject/BOUT-dev#1641?
| @@ -181,6 +181,12 @@ def _trim(ds, ghosts={}, keep_guards=True): | |||
|
|
|||
| trimmed_ds = trimmed_ds.drop(_BOUT_TIMING_VARIABLES, errors='ignore') | |||
|
|
|||
| # Ignore FieldPerps for now | |||
| for name in trimmed_ds: | |||
| if (trimmed_ds[name].dims == ('x', 'z') | |||
There was a problem hiding this comment.
Do FieldPerps not have any identifying features other than their literal dimensions? Like an attributes flag?
There was a problem hiding this comment.
FieldPerps do have an attribute yindex_global which other fields don't have, but I think at the moment the convention for identifying Field3D, Field2D, FieldPerp in netCDF files is by their dimensions. In the current setup this is unambiguous; are you thinking it'll cause problems when adding 'physical' coordinates, etc.? It would be easy to add an attribute like bout_type - this is already done in BOUT++ for the HDF5 input/output because HDF5 variables don't have dimensions that we could use to identify them.
There was a problem hiding this comment.
Okay that seems fine for now then
|
|
| @@ -181,6 +181,12 @@ def _trim(ds, ghosts={}, keep_guards=True): | |||
|
|
|||
| trimmed_ds = trimmed_ds.drop(_BOUT_TIMING_VARIABLES, errors='ignore') | |||
|
|
|||
| # Ignore FieldPerps for now | |||
| for name in trimmed_ds: | |||
| if (trimmed_ds[name].dims == ('x', 'z') | |||
There was a problem hiding this comment.
Okay that seems fine for now then
Ignore FieldPerps when loading datasets
BOUT++ 4.3 will be able to save
FieldPerps to dump files. They will not be consistent across all processors, so require some special handling. In principle we could do something smart (see below), but for now just ignore allFieldPerps so that we can load data-sets that include them and read other fields.FieldPerps are saved with a global y-index as an attribute, andFieldPerps representing physical quantities (e.g. the flux at a divertor target) should have that index set to either a single, consistent value (on the processes where theFieldPerpactually is) or a negative value (on all other processes). So with some special handling they could be loaded sensibly. There is no global checking, so aFieldPerpcould for example be written from all processes, but then it cannot represent a single physical quantity and we should leave it to the user to handle separately.