check if a variable is a FieldPerp as we already do (checking it has x and z dimensions)
get it's yindex_global attribute
if yindex_global == -1 then ignore it. -1 means it is not a valid FieldPerp - there might be data in it, but we do not have to support getting it automatically. The user can get it out with boututils.Datafile or similar if they really want it.
if yindex_global >= 0 then read the FieldPerp. Probably the best thing to do would be to rename it appending the value of yindex_global to the name, because a FieldPerp variable with the same name might have been written at different positions with different values of yindex_global. For example a sheath-boundary heat flux might be written at both lower and upper divertor targets in a double null configuration using the same variable.
if a FieldPerp is saved with the same yindex_global on processors with different y-processor index PE_YIND this should be an error.
For reading, need to work out how the requirements above can be implemented with xarray's combining methods. Hopefully it might 'just work'. I'm not sure right now what happens to variables that are present in some files but not others.
If we find that a FieldPerp was read at only one, unique yindex_global then I guess we could remove the suffix from its variable name, but that would require more special-case code so I'd vote against unless someone wants that feature badly.
When writing out the FieldPerps:
save() creates a single file, so I think we have to write with yindex_global still appended to the variable name
create_restarts() needs to work out which files to write the FieldPerp() into (the ones where yindex_global is within the grid or boundary cells) and needs to remove the suffix from the variable name.
Currently
FieldPerpvariables are not supported, we just skip them when loading https://github.com/boutproject/xBOUT/blob/1f2090e0167b5147a0489889151a76c625b47fc9/xbout/load.py#L700-L707Following discussion here https://github.com/boutproject/BOUT-dev/pull/2102#pullrequestreview-496349751, I think what we want to do is:
FieldPerpas we already do (checking it hasxandzdimensions)yindex_globalattributeyindex_global == -1then ignore it.-1means it is not a validFieldPerp- there might be data in it, but we do not have to support getting it automatically. The user can get it out withboututils.Datafileor similar if they really want it.yindex_global >= 0then read theFieldPerp. Probably the best thing to do would be to rename it appending the value ofyindex_globalto the name, because aFieldPerpvariable with the same name might have been written at different positions with different values ofyindex_global. For example a sheath-boundary heat flux might be written at both lower and upper divertor targets in a double null configuration using the same variable.FieldPerpis saved with the sameyindex_globalon processors with different y-processor indexPE_YINDthis should be an error.For reading, need to work out how the requirements above can be implemented with
xarray's combining methods. Hopefully it might 'just work'. I'm not sure right now what happens to variables that are present in some files but not others.If we find that a
FieldPerpwas read at only one, uniqueyindex_globalthen I guess we could remove the suffix from its variable name, but that would require more special-case code so I'd vote against unless someone wants that feature badly.When writing out the
FieldPerps:save()creates a single file, so I think we have to write withyindex_globalstill appended to the variable namecreate_restarts()needs to work out which files to write theFieldPerp()into (the ones whereyindex_globalis within the grid or boundary cells) and needs to remove the suffix from the variable name.