Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Trivial issues with output and error files #49

Closed
AndyHoggANU opened this issue Nov 3, 2017 · 5 comments
Closed

Trivial issues with output and error files #49

AndyHoggANU opened this issue Nov 3, 2017 · 5 comments

Comments

@AndyHoggANU
Copy link
Contributor

A minor thing which would be nice to fix. We are getting two warnings which are swamping the access.err files:

WARNING from PE 186: set_date_c: Year zero is invalid. Resetting year to 1

WARNING from PE 0: diag_manager_mod::register_diag_field: module/output_field ocean_model/mass_river_on_nrho NOT found in diag_table

They don't affect the model of course, it just makes it harder to look through the output files. Would be nice to clean up if we know why they are happening.

@russfiedler
Copy link

@AndyHoggANU You have debug_diag_manager = .true. in the 0.25 degree runs. Just make this false or remove it and you will get rid of the "NOT found" message. The first message seems to be coming from within ocean_sbc.F90 and looks as if it might be the surface restoring.

WARNING from PE 0: set_date_c: Year zero is invalid. Resetting year to 1

==>Note from ocean_sbc_mod: applying surface restoring to temp

WARNING from PE 0: set_date_c: Year zero is invalid. Resetting year to 1

I can see files like /short/v45/amh157/zz-temp-access-om2/input/mom_1deg/temp_sfc_restore.nc with
TIME:units = "days since 0000-01-01 00:00:00". Change the year from 0000 to 0001. The zero year is a Ferret quirk for climatologies.

@aekiss
Copy link
Contributor

aekiss commented Nov 3, 2017

leaving debug_diag_manager = .true. may be the lesser of two evils as it at least gives some warning if we've misspelled a diag name....?

@russfiedler
Copy link

There's over 1300 notifications for missing diagnostics so I'm not too sure if it's useful except for the initial setting up of the table. I'm not sure if there's a check for requesting output for a non existent quantity. That's easy to test though.

@AndyHoggANU
Copy link
Contributor Author

Yes, I agree that's a bit of overkill. I will turn this off for now in my runs, but maybe we should think about turning this on again if we are playing with the diag_table (provided it does actually check for non-existent diagnostics).

Will look at those files next week.

@aekiss
Copy link
Contributor

aekiss commented Aug 26, 2019

We have debug_diag_manager=false in the new configurations.

I've also fixed start year in new inputs_rc

ncatted -O -a units,time,m,char,"months since 0001-01-01 00:00:00" /short/public/access-om2/input_rc/mom_025deg/salt_sfc_restore.nc
ncatted -O -a units,time,m,char,"months since 0001-01-01 00:00:00" /short/public/access-om2/input_rc/mom_1deg/salt_sfc_restore.nc
ncatted -O -a units,time,m,char,"days since 0001-01-01 00:00:00" /short/public/access-om2/input_rc/mom_1deg/ssw_atten_depth.nc
ncatted -O -a units,TIME,m,char,"days since 0001-01-01 00:00:00" /short/public/access-om2/input_rc/mom_1deg/temp_sfc_restore.nc

check:

for d in /short/public/access-om2/input_rc/mom*/*.nc; do echo $d; grep "since 0000" <(ncdump -h $d); done

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants