Various CGYRO bugfixes

[physycola]

This PR is intended to update PYRO to be compatible with some of the more recent CGYRO changes. Specifically, these are:

1. A CGYRO recent commit changed the sign of the normalisation of the QL fluxes. If I am tracking the definitions of correctly in cgyro_make_profiles.F90, this means that the sign of flux_norm should be modified as shown. This gives good agreement of the QL computed before and after the change, for a case I have, but this breaks the automatic tests.

2. CGYRO is doing away with Z_EFF and Z_EFF_METHOD as input parameters (these will give the CGYRO: bogus parameter message). The easiest way to handle these in PYRO is to remove them from set(), meaning that the user will have to specify them manually now if they want behaviour different from the current functionality of Z_EFF_METHOD=2.

Happy to take feedback @bpatel2107

[bpatel2107]

Hmm so we are getting into dangerous territory here with the code version becoming important. If we just implement the changes here as is then we break backwards compatibility with already existing CGYRO runs. CGYRO does store its git commit here so we could do some fancy stuff here with checking git commits and checking when that occurred though that could be a bit onerous.

I think removing the Z_EFF terms from the set method is a bit hacky and we should delete it in gk_input.data as that is the dictionary that is being used to write things but again we risk breaking backwards compatibility.

@ZedThree thoughts on how to proceed?

[physycola]

I agree that it's a bit annoying about the code versions. To aid decision-making, the Z_EFF change had not yet been made in the master branch of CGRYO, while the other sign change has. So we could always defer the former changes until those are integrated into master, and just fix the QL flux signs? But I guess this also still breaks backwards compatibility, so....

[ZedThree]

Broadly speaking, I think there are two ways of dealing with things like this: either have separate implementations for incompatible versions of a code (but that use a common base class), or have conditionals in the one implementation.

Separate implementations for different versions might add a bunch of complexity, but the benefit is that they can be named, which would allow users to explicitly do cross-version comparisons -- CODE-vX vs CODE-vX+1.

In any case, it might be difficult to deal with builds from between releases -- how do you tell if a run was down before or after a particular bug fix or change in behaviour if it's not exactly version X.Y.Z or X.Y.Z+1?

[FelixWattsYork]

I don't know if this is bad etiquette to add this change to the pre-exisitng PR but I thought it was less work that create a new branch and PR.
Changed default loading of CGYRO binary data to only have read permission as opposed to read and write permission (which is what np.memmap defaults to). This allows reading of CGYRO data from locations you have read access but not write access, ensures binary output data is not modified accidentally, and is consistent with how GENE data is loaded

[bpatel2107]

I think I'm happy enough for now so will merge and see what problems arise!

[bpatel2107]

We should actually do something before the open like

del self.data["Z_EFF"]