z and zi not function of time in output when zeta is fixed and no ice model

[bderembl]

This PR address the old (and closed...) issue #45.

With these minor modifications, we can have a stationary z grid in the netcdf file (i.e. z and zi do not depend on time). this is very helpful in many ways: when loading the netcdf in python and with ncview to get the correct z axis.

z axis function of time should should still work when zeta varies or when there is an ice model.

the idea is just to compute a flag
fixed_grid = (zeta_input%method == 0) .and. (ice_model == 0)
in gotm.F90

and then in register_variables, decide whether or not z and zi are function of time based on this flag

side note (not implemented here): we could also envision that lat and lon are function of time (following an argo float for instance). but yes, it is convenient to have fixed lat lon (current behavior)

[bolding]

Hi Bruno

But does having the grid constant in time - but still containing the time dimension - ruin anything? If it is for plotting the plot program should figure it out.

I actually think either PML or OGS has made GOTM similations following an ARGO float. That could be interesting to get into the main branch - and should not be that difficult. Things to look out for is the actual depth and of course getting meteo at the right position. Reading lat, lon from a file should be relative straight forward.

Karsten

[bderembl]

yes, for some reason the problems with xarray mentioned in #45 are still present. for me the main issue is with ncview: fields are plotted against the index and not the actual z value.

the behavior introduced in this pull request should really not affect the cases where the grid is variable in time.

[bderembl]

my point with argo float was that: yes in principle, we could have lat, lon function of time but it is very convenient for most cases to have them NOT function of time.

I thought the same could apply for z: in some cases it is function of time but in other cases, it is not. when it is not function of time, no need to artificially add it in the output file

[bolding]

I think there is a difference - zi, z are prognostic variables of the model - not so for lat, lon

[bderembl]

yes, that's precisely my point: sometimes z and zi are prognostic variables (and so should be treated as prognostic variables); sometimes they are not (and should not be treated as such)

[jornbr]

To me, this sounds like a valuable feature to incorporate. I'd prefer it to be an option in gotm.yaml though, so it is still possible to generate the classic z and zi coordinates even if zeta_method=0. That way, we maintain backward compatibility with the many postprocessing workflows out there (not in the least our own!) Then we can just argue about whether that new option should be on or off by default. ;-)

[bolding]

" Then we can just argue about whether that new option should be on or off by default. ;-)" - or having an enlightened discussion ....