[getm-users: 0] netcdf hotstart variable missing

[e...@buchmann.dk]

Hi,

At DaMSA we are making annual reruns to test new GETM features to improve
the overall accuracy and reliability of our forecasts.
We have old hotstart files saved, so in principle, we should be able to
run starting at any previous month. The first obstacle is that the old
hotstart files are binary formatted, and they cannot be read by new source
getm. We have the old binaries around, though, so running zero (or short)
time and saving to netcdf is not a problem.

However, when I then read the netCDF hotstart files with a newer version
of GETM, I get the following error:


/scratch/valid/RUNDIRS/GETMRUN/getmrun-NS1C-hindcast_v005D_200809010000/restart.000.in
FATAL ERROR: open_restart_ncdf:
NetCDF: Variable not found
open_restart_ncdf

The content of the hotstart files follow:
[]$ ncdump -h restart.000.in
netcdf restart.000 {
dimensions:
xax = 72 ;
yax = 72 ;
zax = 61 ;
variables:
int loop ;
int julianday ;
int secondsofday ;
double timestep ;
double xax(xax) ;
double yax(yax) ;
double zax(zax) ;
double z(yax, xax) ;
double zo(yax, xax) ;
double U(yax, xax) ;
double zu(yax, xax) ;
double zub(yax, xax) ;
double SlUx(yax, xax) ;
double Slru(yax, xax) ;
double V(yax, xax) ;
double zv(yax, xax) ;
double zvb(yax, xax) ;
double SlVx(yax, xax) ;
double Slrv(yax, xax) ;
double ssen(yax, xax) ;
double ssun(yax, xax) ;
double ssvn(yax, xax) ;
double sseo(yax, xax) ;
double ssuo(yax, xax) ;
double ssvo(yax, xax) ;
double Uinto(yax, xax) ;
double Vinto(yax, xax) ;
double uu(zax, yax, xax) ;
double vv(zax, yax, xax) ;
double ww(zax, yax, xax) ;
double uuEx(zax, yax, xax) ;
double vvEx(zax, yax, xax) ;
double tke(zax, yax, xax) ;
double eps(zax, yax, xax) ;
double num(zax, yax, xax) ;
double nuh(zax, yax, xax) ;
double T(zax, yax, xax) ;
double S(zax, yax, xax) ;

// global attributes:
:title = "GETM NetCDF hotstart file" ;
:history = "Generated by GETM, ver. 1.7.0" ;
}

Next, I will try to make a netCDF hotstart file with a newer version of
the code and look for changes, but if anybody already know what is
wrong/missing, please tell me. Is it something, that I can fix easily
(with e.g. ncap/ncap2 to add variables etc)?

Hope to hear from you.

Best,

Bjarne B�chmann

[e...@buchmann.dk]

Hi,

<snip>

> The content of the hotstart files follow:

<snip>

> double num(zax, yax, xax) ;
> double nuh(zax, yax, xax) ;

Looks like hn is missing here, right(?)

> double T(zax, yax, xax) ;
> double S(zax, yax, xax) ;

<snip>

So I need to "come up with" a start field for hn.
We run a fully 3D (runtype=4) with 60 layers and:

vert_cord=3
kdum=60
ddu=2.
ddl=1.
d_gamma=25.
gamma_surf=.true.

Any ideas on what to put in? I rerun the old binary (again) and probably
get the data from 3D output, right? But is that the best path for this
problem?

Best,

Bjarne B�chmann

[Johan Van Der Molen (Cefas)]

Bjarne,

I've had a look in one of our recent hotstart files, and there's a difference: yours has variables zub and zvb that ours don't have. That can't be your problem, but it might be of interest?

Note that ours don't have hn, but work fine. Must say that that seems odd.

Best wishes,
Johan

> Bjarne Büchmann
>
>



***********************************************************************************
This email and any attachments are intended for the named recipient only. Its unauthorised use, distribution, disclosure, storage or copying is not permitted. If you have received it in error, please destroy all copies and notify the sender. In messages of a non-business nature, the views and opinions expressed are the author's own and do not necessarily reflect those of the organisation from which it is sent. All emails may be subject to monitoring.
***********************************************************************************

[Karsten Bolding]

On Thu, May 20, 2010 at 09:18:14 +0200, e...@buchmann.dk wrote:
> Hi,
>

<snip>

>
> However, when I then read the netCDF hotstart files with a newer version
> of GETM, I get the following error:

the reading of NetCDF based hot-start files happens in:
...../ncdf/read_restart_ncdf.F90

If I gop through the list of variables read in this file and the list
you provide below I can't find any that are read in and NOT in your
file. There are variables in your file NOT read in - but that is not the
issues here - and there are reasons for that.

Have you any specific compilation options?

In the log file there is not more usefull information than what you show
below?

Way forward might be to insert printg statements between the
individual reads in read_restart_ncdf.F90 to find out which variable
causes the problem.

<snip>

>
> Best,
>
> Bjarne B�chmann
>

Karsten
>
>
>

--
http://www.getm.eu

[Karsten Bolding]

On Thu, May 20, 2010 at 09:37:45 +0200, e...@buchmann.dk wrote:
> Hi,
>
> <snip>
>
> > The content of the hotstart files follow:
>
> <snip>
>
> > double num(zax, yax, xax) ;
> > double nuh(zax, yax, xax) ;
>
> Looks like hn is missing here, right(?)

but we don't attempt to read hn - and if you look in
../getm/initialise.F90 around line 367 to 372 you can see hn is
calculated.

[e...@buchmann.dk]

Hi,

<snip>

>> Looks like hn is missing here, right(?)
>
> but we don't attempt to read hn - and if you look in
> ../getm/initialise.F90 around line 367 to 372 you can see hn is
> calculated.

Hmm... In the code I try to run (it is not the most recent - but from
2010-03-25, "open_restart_ncdf.F90" clearly tries to verify that hn is in
there. Lines 167-168:

status = nf90_inq_varid(ncid, "hn", hn_id)
if (status .NE. NF90_NOERR) go to 10

In read_restart_ncdf.F90, from lines 419 onwards I have:

! hn is required for adaptive coordinates
status = &
nf90_get_var(ncid,hn_id,hn(iloc:ilen,jloc:jlen,0:kmax),start,edges)
if (status .NE. NF90_NOERR) go to 10

Is this not as it should be?

Best,

Bjarne

[Richard Hofmeister]

Hi Bjarne,

Reading hn in the restart files should be disabled in the stable version
of GETM (it is anyhow not used in the simulation). The developers
version (the upcoming stable version within 10 months) will have a
different, more flexible coordinates handling using hn from the restarts
(e.g. for adaptive coordinates).

A developers comment: I recommend to keep the writing of hn in the
hotstart files, even for the stable version in order to allow for
rerunning the setups also with the upcoming stable version.

Richard

--

Richard Hofmeister
Leibniz Institute for Baltic Sea Research
Seestr. 15, 18119 Warnem�nde
Tel: 0381-5197103 Fax: 0381-5197440

[e...@buchmann.dk]

Hi,

> Hmm... In the code I try to run (it is not the most recent - but from
> 2010-03-25

<snip>

Just got a new/clean devel version, and it does in fact not try to access
hn from netcdf hotstart. So I will try with that code.

> Is this not as it should be?

Obviously not.

Bjarne

[Karsten Bolding]

On Thu, May 20, 2010 at 09:57:30 +0200, Richard Hofmeister wrote:
> Hi Bjarne,
>
> Reading hn in the restart files should be disabled in the stable
> version of GETM (it is anyhow not used in the simulation). The
> developers version (the upcoming stable version within 10 months)
> will have a different, more flexible coordinates handling using hn
> from the restarts (e.g. for adaptive coordinates).
>
> A developers comment: I recommend to keep the writing of hn in the
> hotstart files, even for the stable version in order to allow for
> rerunning the setups also with the upcoming stable version.

every change related to adaptive grids was removed shortly before
release of the stable version. The also included the reading of hn.
Having left the reading of hn and the immidialtely after - in
initialise() - re-calculaitng hn would be confusing.


>
> Richard

Karsten

--
http://www.getm.eu

[Karsten Bolding]

On Thu, May 20, 2010 at 09:51:23 +0200, e...@buchmann.dk wrote:
> Hi,
>
> <snip>
>
> >> Looks like hn is missing here, right(?)
> >
> > but we don't attempt to read hn - and if you look in
> > ../getm/initialise.F90 around line 367 to 372 you can see hn is
> > calculated.
>
> Hmm... In the code I try to run (it is not the most recent - but from
> 2010-03-25, "open_restart_ncdf.F90" clearly tries to verify that hn is in
> there. Lines 167-168:

a version from before the stable release .... it is always a good
idea to keep the code up to date

>
> Bjarne
>

Karsten

--
http://www.getm.eu