[MITgcm-support] user-defined diagnostic filled with zeros
Liam Brannigan
Liam.Brannigan at physics.ox.ac.uk
Tue Aug 18 07:10:06 EDT 2015
Hi Alexandre
It may also be worth a quick check that the array omegaC itself isn't filled with zeros when you are writing to it, especially given that that array is filled with 0 at certain points in the code.
This can be done with a <print *, omegaC> command just before you the call to diagnostics_fill, with the output appearing in the STDOUT files. Obviously, the make command must be run again after modifying the code.
Liam
________________________________________
From: mitgcm-support-request at mitgcm.org [mitgcm-support-request at mitgcm.org]
Sent: 17 August 2015 17:00
To: mitgcm-support at mitgcm.org
Subject: MITgcm-support Digest, Vol 146, Issue 13
Send MITgcm-support mailing list submissions to
mitgcm-support at mitgcm.org
To subscribe or unsubscribe via the World Wide Web, visit
http://mitgcm.org/mailman/listinfo/mitgcm-support
or, via email, send a message with subject or body 'help' to
mitgcm-support-request at mitgcm.org
You can reach the person managing the list at
mitgcm-support-owner at mitgcm.org
When replying, please edit your Subject line so it is more specific
than "Re: Contents of MITgcm-support digest..."
Today's Topics:
1. user-defined diagnostic filled with zeros (Alexandre Pohl)
2. Re: user-defined diagnostic filled with zeros (Jean-Michel Campin)
3. Re: obcs with staggered grid (Jean-Michel Campin)
----------------------------------------------------------------------
Message: 1
Date: Mon, 17 Aug 2015 09:19:09 +0200
From: Alexandre Pohl <alexandre.pohl at lsce.ipsl.fr>
To: mitgcm-support at mitgcm.org
Subject: [MITgcm-support] user-defined diagnostic filled with zeros
Message-ID: <6D566AA2-8577-42FB-AF25-028DF631AF61 at lsce.ipsl.fr>
Content-Type: text/plain; charset="utf-8"
Dear all,
I am using a coupled configuration of the MITgcm with the pkg/DIC and pkg/diagnostics enabled. I would like to add a new diagnostic to the permanent set of diagnostics in the model: 'omegaC' (computed in 'dic/calcite_saturation.F').
I followed the instructions from the guidebook (http://mitgcm.org/public/r2_manual/latest/online_documents/node269.html <http://mitgcm.org/public/r2_manual/latest/online_documents/node269.html>):
1] First, I define the new diagnostic in 'dic_diagnostics_init.F' :
diagName = 'OMEGAC '
diagTitle = 'Calcite Omega '
diagUnits = 'dimensionless '
diagCode = 'SMRP MR '
CALL DIAGNOSTICS_ADDTOLIST( diagNum,
I diagName, diagCode, diagUnits, diagTitle, 0, myThid )
2] Then, I call the 'DIAGNOSTICS_FILL' routine in 'dic_biotic_forcing.F'.
CALL DIAGNOSTICS_FILL(SURC ,'DICTFLX ',0,1 ,2,bi,bj,myThid) <==== one of pkg/DIC default diagnostics
CALL DIAGNOSTICS_FILL(omegaC ,'OMEGAC ',0,Nr,1,bi,bj,myThid) <==== my new diag
#ifdef ALLOW_O2
CALL DIAGNOSTICS_FILL(SURO ,'DICOFLX ',0,1 ,2,bi,bj,myThid) <==== another pkg/DIC default diagnostic
Compilation succeeds, the model runs and diagnostics are successfully written in the model output mdsio files. The problem is that the newly added diagnostic, OMEGAC, is filled with zeros. I guess that it has something to do with either 'diagCode' from step 1 (which I set to 'SMRP MR ' like for DICBIOA, which seemed to be correct after Table 7.1: http://mitgcm.org/public/r2_manual/latest/online_documents/node268.html <http://mitgcm.org/public/r2_manual/latest/online_documents/node268.html>), or with the bibjFlg from step 2 (which I set to 1 because omegaC is not modified in 'dic_biotic_forcing.F', following instructions given at the top of the same page).
Could anyone tell me what I am doing wrong?
Thanks!
Alexandre
__
Alexandre POHL
PhD Student
Laboratoire des Sciences du Climat et de l?Environnement (LSCE)
Centre d'Etude de Saclay
CEA-Orme des Merisiers, b?t. 701
F-91191 GIF-SUR-YVETTE CEDEX
FRANCE
alexandre.pohl at lsce.ipsl.fr
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mitgcm.org/pipermail/mitgcm-support/attachments/20150817/ace8ab62/attachment.html>
------------------------------
Message: 2
Date: Mon, 17 Aug 2015 07:16:25 -0400
From: Jean-Michel Campin <jmc at ocean.mit.edu>
To: mitgcm-support at mitgcm.org
Subject: Re: [MITgcm-support] user-defined diagnostic filled with
zeros
Message-ID: <20150817111625.GA3008 at ocean.mit.edu>
Content-Type: text/plain; charset=iso-8859-1
Hi Alexandre,
There has been 3 reply to a previous, similar email sent on Aug 05:
http://mitgcm.org/pipermail/mitgcm-support/2015-August/010036.html
Could you try to answer these messages, and specially these 2:
http://mitgcm.org/pipermail/mitgcm-support/2015-August/010037.html
http://mitgcm.org/pipermail/mitgcm-support/2015-August/010049.html
Cheers,
Jean-Michel
On Mon, Aug 17, 2015 at 09:19:09AM +0200, Alexandre Pohl wrote:
> Dear all,
>
> I am using a coupled configuration of the MITgcm with the pkg/DIC and pkg/diagnostics enabled. I would like to add a new diagnostic to the permanent set of diagnostics in the model: 'omegaC' (computed in 'dic/calcite_saturation.F').
>
> I followed the instructions from the guidebook (http://mitgcm.org/public/r2_manual/latest/online_documents/node269.html <http://mitgcm.org/public/r2_manual/latest/online_documents/node269.html>):
>
> 1] First, I define the new diagnostic in 'dic_diagnostics_init.F' :
>
> diagName = 'OMEGAC '
> diagTitle = 'Calcite Omega '
> diagUnits = 'dimensionless '
> diagCode = 'SMRP MR '
> CALL DIAGNOSTICS_ADDTOLIST( diagNum,
> I diagName, diagCode, diagUnits, diagTitle, 0, myThid )
>
> 2] Then, I call the 'DIAGNOSTICS_FILL' routine in 'dic_biotic_forcing.F'.
>
> CALL DIAGNOSTICS_FILL(SURC ,'DICTFLX ',0,1 ,2,bi,bj,myThid) <==== one of pkg/DIC default diagnostics
> CALL DIAGNOSTICS_FILL(omegaC ,'OMEGAC ',0,Nr,1,bi,bj,myThid) <==== my new diag
> #ifdef ALLOW_O2
> CALL DIAGNOSTICS_FILL(SURO ,'DICOFLX ',0,1 ,2,bi,bj,myThid) <==== another pkg/DIC default diagnostic
>
> Compilation succeeds, the model runs and diagnostics are successfully written in the model output mdsio files. The problem is that the newly added diagnostic, OMEGAC, is filled with zeros. I guess that it has something to do with either 'diagCode' from step 1 (which I set to 'SMRP MR ' like for DICBIOA, which seemed to be correct after Table 7.1: http://mitgcm.org/public/r2_manual/latest/online_documents/node268.html <http://mitgcm.org/public/r2_manual/latest/online_documents/node268.html>), or with the bibjFlg from step 2 (which I set to 1 because omegaC is not modified in 'dic_biotic_forcing.F', following instructions given at the top of the same page).
>
> Could anyone tell me what I am doing wrong?
>
> Thanks!
> Alexandre
>
> __
>
> Alexandre POHL
> PhD Student
> Laboratoire des Sciences du Climat et de l???Environnement (LSCE)
> Centre d'Etude de Saclay
> CEA-Orme des Merisiers, b?t. 701
> F-91191 GIF-SUR-YVETTE CEDEX
> FRANCE
> alexandre.pohl at lsce.ipsl.fr
> _______________________________________________
> MITgcm-support mailing list
> MITgcm-support at mitgcm.org
> http://mitgcm.org/mailman/listinfo/mitgcm-support
------------------------------
Message: 3
Date: Mon, 17 Aug 2015 08:16:19 -0400
From: Jean-Michel Campin <jmc at ocean.mit.edu>
To: mitgcm-support at mitgcm.org
Subject: Re: [MITgcm-support] obcs with staggered grid
Message-ID: <20150817121619.GA7430 at ocean.mit.edu>
Content-Type: text/plain; charset=us-ascii
Hi Gordon,
I did not see any answer to your message; below are some (late) comments.
On Mon, Aug 10, 2015 at 10:12:24PM -0400, Weifeng (Gordon) Zhang wrote:
> Hi,
>
> I am a little puzzled by the way mitgcm handles the open boundary
> conditions.
>
> In obcs_cal.F, OBWu, OBWv, OBWw, OBWt, and OBWs are specified. Are
> these variables at the same grid locations (the model does the
> interpolation/extroplation internally), or they are at their own
> staggered grid locations with half-grid offsets?
The model does not interpolate OBCS values: They are supposed to be
at the right location, i.e. on the staggered grid, at the OB location.
You could find some information in the manual, section 6.3.1.4
> If the variables are at the staggered grid locations, how come they
> have the same size in all directions? Shouldn't there be a size
> offset of 1 in some of the variables, for instance, OBWv's size in y
> being greater than the y-size of the other variables by 1, and
> OBWw's vertical size being greater than the other variables by 1?
All input binary files (e.g., initial Temp,Salt U,V ...) have the
same size, no difference between U,V and T,S, as well as all output (*.data)
binary files. And this is also the case for OBC input fields.
> For OBWw, because it is 0 on the bottom interface, the bottom OBWw
> is neglected? What about OBWv then, how is it handled on the north
> and south boundaries?
May be getting familiar with MITgcm plain binary output in a simple
set-up (one of the tutorials) might help to figure out how OBCS input
files work ?
Cheers,
Jean-Michel
>
> Thanks,
>
> Gordon
>
>
> _______________________________________________
> MITgcm-support mailing list
> MITgcm-support at mitgcm.org
> http://mitgcm.org/mailman/listinfo/mitgcm-support
------------------------------
_______________________________________________
MITgcm-support mailing list
MITgcm-support at mitgcm.org
http://mitgcm.org/mailman/listinfo/mitgcm-support
End of MITgcm-support Digest, Vol 146, Issue 13
***********************************************
More information about the MITgcm-support
mailing list