[MITgcm-support] EXF and Calendar Package
Andres Fernandez
andres.fernandez at nyu.edu
Thu Aug 7 18:52:21 EDT 2014
Thank you all for your tremendous support !
Things seem to be moving forward. I just do not seem to be able to
successfully run a basic evaporation forcing (EXF_READ_EVAP) I have done
the following:
in the EXE_OPTIONS.h I added the following:
C Bulk formulae related flags.
#undef ALLOW_ATM_TEMP
#undef ALLOW_ATM_WIND
#undef ALLOW_DOWNWARD_RADIATION
#undef ALLOW_RUNOFF
C I added EXF_READ_EVAP below
#define EXF_READ_EVAP
I compiled....
and then the data.exf file I have and the data file are the following:
https://www.dropbox.com/sh/l3ajr61zbb7v94u/AADX32m0dSoDj69apzgFlfvLa
I have no latitude and longitude information on the model; that is why I
commented out longitude and latitude. I also added #undef
USE_EXF_INTERPOLATION because it required latitude longitude, if I am not
mistaken?
and I get an error:
forrtl: severe (24): end-of-file during read
the STDOUT ends here:
(PID.TID 0000.0001) EXF_READPARMS: reading EXF_NML_01
(PID.TID 0000.0001) EXF_READPARMS: reading EXF_NML_02
(PID.TID 0000.0001) EXF_READPARMS: reading EXF_NML_03
(PID.TID 0000.0001) EXF_READPARMS: reading EXF_NML_04
(PID.TID 0000.0001) EXF_READPARMS: reading EXF_NML_OBCS
Thank you for all your help!
*Andres Fernandez*
Undergraduate Chemical Engineering
New York University Abu Dhabi - 2015
Mobile (USA): +1 646 717 2231
*Think before printing. The environment is in our hands
On Thu, Aug 7, 2014 at 1:42 AM, Jean-Michel Campin <jmc at ocean.mit.edu>
wrote:
> Hi All,
>
> I am not going to comment too much on this specific error message
> (since, given the information in this message, it's going to be
> very difficult to reproduce it from a fresh built) but rather on
> the circumstances where a full cleaning ("make Clean" or even the
> stronger "make CLEAN") is needed.
>
> It's generally OK to just type "make" when changes have been made in
> some source files (*.h or *.F) while keeping the location of any source
> file unchanged.
>
> Otherwise, any time one or more source file is moved around (for instance,
> added to one of the setup-specific local dir that is given in the "-mods"
> argument list of genmake2) or a package is added (to the packages.conf
> file) or a preprocessor (CPP) header file (*_OPTIONS.h) is changed,
> or, for adjoint built, a flow directive or AD diff list is changed,
> then it's safer to go for a full clean: "make Clean"
> before re-building a new executable (make makefile ; make depend ; make).
>
> And finally, it could be very useful to check for any error (not so much
> warnings that are more dependent on the preprocessor CPP version and
> default options) at the "make depend" stage (although a fail at this stage
> might not prevent to continue the building sequence): these errors
> are generally easy to figure out and therefore easy to fix.
>
> Note that, in the special case of an OpenAD built (without a "make depend"
> stage), the remarks above don't apply and a full cleaning might be safer
> (to be confirmed).
>
> Cheers,
> Jean-Michel
>
> On Wed, Aug 06, 2014 at 07:17:47PM -0400, Andres Fernandez wrote:
> > When I add gmredi to packages.conf I get the following error when
> > compiling:
> >
> > Any comments on this? How do define the type?
> >
> > mredi_calc_diff.f(3305): error #6404: This name does not have a type, and
> > must have an explicit type. [GAD_TR1]
> > IF (tracerIdentity .LT. GAD_TR1) THEN
> > -----------------------------------^
> > compilation aborted for gmredi_calc_diff.f (code 1)
> > make[1]: *** [gmredi_calc_diff.o] Error 1
> > make[1]: *** Waiting for unfinished jobs....
> >
> >
> >
> >
> >
> >
> > *Andres Fernandez*
> > Undergraduate Chemical Engineering
> > New York University Abu Dhabi - 2015
> > Mobile (USA): +1 646 717 2231
> >
> > *Think before printing. The environment is in our hands
> >
> >
> > On Wed, Aug 6, 2014 at 3:16 AM, Martin Losch <Martin.Losch at awi.de>
> wrote:
> >
> > > Hi Andres,
> > >
> > > the files you posted do compile on my computer, but you didn't post the
> > > correct data/input files.
> > >
> > > I wonder why you have 40 CPUs for a 100 by 80 domain. For testing I
> would
> > > use 1CPU and then run the model interactively. That's what I did
> > > (nPx/nPy=1, nSx=5, nSy=8).
> > >
> > > The "data"-file does not contain the appropriate delR. I replaced it
> with
> > > the "data.odt" that you posted earlier (not a good idea to post an
> ascii
> > > file in a specific text editor format). Then I have no problems
> reading the
> > > file, except that you put in namelist parameters, that do not exist:
> > >
> > > (PID.TID 0000.0001)
> > > (PID.TID 0000.0001) INI_PARMS ; starts to read PARM01
> > > (PID.TID 0000.0001) INI_PARMS ; read PARM01 : OK
> > > (PID.TID 0000.0001) INI_PARMS ; starts to read PARM02
> > > (PID.TID 0000.0001) INI_PARMS ; read PARM02 : OK
> > > (PID.TID 0000.0001) INI_PARMS ; starts to read PARM03
> > > (PID.TID 0000.0001) INI_PARMS ; read PARM03 : OK
> > > (PID.TID 0000.0001) INI_PARMS ; starts to read PARM04
> > > (PID.TID 0000.0001) INI_PARMS ; read PARM04 : OK
> > > (PID.TID 0000.0001) INI_PARMS ; starts to read PARM05
> > > At line 3212 of file ini_parms.f (unit = 11, file =
> > > '/var/folders/r2/jkk7t8vd2vjcb7h_gp0_g19h0000gq/T/gfortrantmp0GwsWQ')
> > > Fortran runtime error: Cannot match namelist object name evapfile
> > >
> > > BTW, that's also what your system error file dotEfile.odt suggests.
> > >
> > > Please have a look at model/src/ini_parms.F to find out which
> parameters
> > > you can specifiy in the namelists in "data"
> > >
> > > - after commenting out
> > > # evapfile='evaporation_data.bin'
> > > # precipfile='precipitation_data.bin'
> > > The model stops here:
> > > from PACKAGES_CHECK: run-time control flag useGMRedi is set
> > > but pkg/gmredi was not compiled (ALLOW_GMREDI undef).
> > > ==> Re-compile with pkg "gmredi" in file "packages.conf"
> > > S/R ALL_PROC_DIE: ending the run
> > > STOP ABNORMAL END: S/R PACKAGE_ERROR_MSG
> > >
> > > I guess the error message is self-explanatory, and then after
> commenting
> > > out useGMredi = .TRUE. in data.pkg, I get
> > >
> > > CONFIG_CHECK: #undef ALLOW_NONHYDROSTATIC and
> > > CONFIG_CHECK: nonHydrostatic is TRUE
> > > CONFIG_CHECK: detected 1 fatal error(s)
> > > S/R ALL_PROC_DIE: ending the run
> > > STOP ABNORMAL END: S/R CONFIG_CHECK
> > >
> > > again, it should be clear what this means (if you want to use
> > > nonHydrostatic=.TRUE. you have to set ALLOW_NONHYDROSTATAIC in
> > > CPP_OPTIONS.h). It also tells me, that you posted a combination of
> > > CPP-flags and namelist parameters that are not compatible. Either
> that's a
> > > mistake or you haven't even gotten that far.
> > >
> > > Hope that helps,
> > >
> > > Martin
> > >
> > > On Aug 6, 2014, at 12:11 AM, Andres Fernandez <
> andres.fernandez at nyu.edu>
> > > wrote:
> > >
> > > > Hi Martin, I have been trying to work off of global_with_exf ....
> Have
> > > not succeeded yet.
> > > >
> > > > Here is the link with my input directories and code directories:
> > > >
> > > > https://www.dropbox.com/sh/l3ajr61zbb7v94u/AADX32m0dSoDj69apzgFlfvLa
> > > >
> > > > Thank you in advance!
> > > > Andres
> > > >
> > > > Andres Fernandez
> > > > Undergraduate Chemical Engineering
> > > > New York University Abu Dhabi - 2015
> > > > Mobile (USA): +1 646 717 2231
> > > >
> > > > *Think before printing. The environment is in our hands
> > > >
> > > >
> > > >
> > > > On Tue, Aug 5, 2014 at 2:27 AM, Martin Losch <Martin.Losch at awi.de>
> > > wrote:
> > > > Hi Andres,
> > > >
> > > > dz(k+1)/dz(k) < sqrt(2) is a rule of thumb (that you should follow).
> The
> > > finite volume discretization requires some averaging to grid cell
> > > interfaces and currently (and I don't believe that this will change)
> this
> > > averaging requires that the grid spacing varies smoothly to avoid large
> > > discretrization errors. The same is true for the horizontal grid
> spacing,
> > > but in the horizontal very irregular grid appear unnatural, right?
> > > >
> > > > Can you gzip/tar your code and input directories and put them
> somewhere
> > > to download and look at (please don't send large files to this list)?
> > > >
> > > > For problems like yours, it makes sense to start from a working
> example
> > > and change it file by file to the actual configuration that you want to
> > > run, so that you can identify the problems individually.
> > > >
> > > > Martin
> > > >
> > > > On Aug 5, 2014, at 12:46 AM, Andres Fernandez <
> andres.fernandez at nyu.edu>
> > > wrote:
> > > >
> > > > > Data file, STDOUT.0000 and the .e file that is generated are
> > > attached...
> > > > > the STDERR.0000 is blank, so i did not attach it.
> > > > >
> > > > > @Nicolas, I was not aware of this limitation of irregular spacing.
> Any
> > > comments from other users?
> > > > >
> > > > >
> > > > > Thank you all!
> > > > >
> > > > >
> > > > > Andres Fernandez
> > > > > Undergraduate Chemical Engineering
> > > > > New York University Abu Dhabi - 2015
> > > > > Mobile (USA): +1 646 717 2231
> > > > >
> > > > > *Think before printing. The environment is in our hands
> > > > >
> > > > >
> > > > >
> > > > > On Mon, Aug 4, 2014 at 5:23 PM, Dustin Carroll <
> dcarroll at uoregon.edu>
> > > wrote:
> > > > > Hi Andres,
> > > > >
> > > > > It would be helpful for you to share your data file...plus the
> last few
> > > lines from STDOUT.0000 and the output from STDERR.0000.
> > > > >
> > > > > Dustin
> > > > >
> > > > > On Aug 4, 2014, at 7:15 PM, Andres Fernandez <
> andres.fernandez at nyu.edu>
> > > wrote:
> > > > >
> > > > >> Dear Dustin,
> > > > >> I realized I had a comma missing in the list when copying you the
> > > delR declaration. I have an irregular spacing declared as follows: So,
> > > thank you.
> > > > >>
> > > > >> delR= 5.0,
> > > > >> 5.0,
> > > > >> 5.0,
> > > > >> 5.0,
> > > > >> 5.0,
> > > > >> 5.0,
> > > > >> 5.0,
> > > > >> 5.0,
> > > > >> 5.0,
> > > > >> 5.0,
> > > > >> 10.0,
> > > > >> 10.0,
> > > > >> 10.0,
> > > > >> 10.0,
> > > > >> 10.0,
> > > > >> 10.0,
> > > > >> 10.0,
> > > > >> 10.0,
> > > > >> 10.0,
> > > > >> 10.0,
> > > > >> 50.0,
> > > > >> 50.0,
> > > > >> 50.0,
> > > > >> 50.0,
> > > > >> 50.0,
> > > > >> &
> > > > >>
> > > > >>
> > > > >>
> > > > >>
> > > > >> ** I do still get an error though!
> > > > >>
> > > > >> forrtl: severe (24): end-of-file during read, unit 11, file
> > > .../fortzlTn72 line 8, position 0
> > > > >> "" ... / fort5xkez2
> > > > >> "" .../ fort2YWOn2fort5xkez2
> > > > >> and a bunch more files..
> > > > >>
> > > > >> Unsure if you could assist with this error?
> > > > >>
> > > > >> @Jean- Michel, I have ran a couple models before and the struggle
> I
> > > have right now is with external forcing, I want to add precipitation
> and
> > > evaporation and I am not succeeding. I have not found any comprehensive
> > > information on the manual.
> > > > >>
> > > > >>
> > > > >>
> > > > >> Andres Fernandez
> > > > >> Undergraduate Chemical Engineering
> > > > >> New York University Abu Dhabi - 2015
> > > > >> Mobile (USA): +1 646 717 2231
> > > > >>
> > > > >> *Think before printing. The environment is in our hands
> > > > >>
> > > > >>
> > > > >>
> > > > >> On Mon, Aug 4, 2014 at 3:58 PM, Dustin Carroll <
> dcarroll at uoregon.edu>
> > > wrote:
> > > > >> Hi Andres,
> > > > >>
> > > > >> The vertical grid spacing (delZ, delP, or delR) is set in your
> data
> > > file. You can specific with a *.bin file, i.e delRfile='dz. bin'
> > > > >>
> > > > >> or without a bin file...delR=100*10
> > > > >>
> > > > >> Cheers,
> > > > >> Dustin
> > > > >>
> > > > >>
> > > > >>
> > > > >>
> > > > >> On Aug 4, 2014, at 5:43 PM, Andres Fernandez <
> > > andres.fernandez at nyu.edu> wrote:
> > > > >>
> > > > >>> Dear support,
> > > > >>>
> > > > >>> I get the (PID.TID 0001.0001) *** ERROR *** S/R INI_PARMS: No
> value
> > > for delZ/delP/delR at k = 16 ....25
> > > > >>> I am unsure where to set these initial conditions... or is this
> when
> > > I build it?
> > > > >>>
> > > > >>> Did I build it incorrectly?
> > > > >>>
> > > > >>> Thank you
> > > > >>>
> > > > >>> Andres Fernandez
> > > > >>> Undergraduate Chemical Engineering
> > > > >>> New York University Abu Dhabi - 2015
> > > > >>> Mobile (USA): +1 646 717 2231
> > > > >>>
> > > > >>> *Think before printing. The environment is in our hands
> > > > >>>
> > > > >>>
> > > > >>>
> > > > >>> On Thu, Jul 31, 2014 at 8:34 PM, Dustin Carroll <
> > > dcarroll at uoregon.edu> wrote:
> > > > >>> Hi Andres,
> > > > >>>
> > > > >>> You can debug this further by looking at your STDERR.0000 file
> for
> > > more specific error information... also take a look at STDOUT.0000 to
> see
> > > where your model crashed. You probably have a syntax error in one of
> your
> > > data files.
> > > > >>>
> > > > >>> Cheers,
> > > > >>> Dustin
> > > > >>>
> > > > >>>
> > > > >>> On Jul 31, 2014, at 9:21 PM, Andres Fernandez <
> > > andres.fernandez at nyu.edu> wrote:
> > > > >>>
> > > > >>>> So I recompiled the executable; and placed it in my input
> folder;
> > > > >>>>
> > > > >>>> I have the following folders:
> > > > >>>>
> > > > >>>> data
> > > > >>>> data.cal
> > > > >>>> data.exf
> > > > >>>> data.obcs
> > > > >>>> data.pkg
> > > > >>>> data.rbcs
> > > > >>>> eedata
> > > > >>>> eedata.mth
> > > > >>>> executable
> > > > >>>> (some binary files)
> > > > >>>>
> > > > >>>> And I get this error when I run:
> > > > >>>> ABNORMAL END: S/R INI_PARMS
> > > > >>>>
> > > > >>>> Thank you for your assistance.
> > > > >>>>
> > > > >>>>
> > > > >>>> Best,
> > > > >>>> Andres
> > > > >>>>
> > > > >>>> Andres Fernandez
> > > > >>>> Mobile (USA): +1 646 717 2231
> > > > >>>>
> > > > >>>> *Think before printing. The environment is in our hands
> > > > >>>>
> > > > >>>>
> > > > >>>>
> > > > >>>> On Thu, Jul 31, 2014 at 3:46 PM, Dustin Carroll <
> > > dcarroll at uoregon.edu> wrote:
> > > > >>>> Hi Andres,
> > > > >>>>
> > > > >>>> also, under code/packages.conf add the line:
> > > > >>>>
> > > > >>>> cal
> > > > >>>>
> > > > >>>> and recompile. Then you should be fine with useEXF=.TRUE., in
> your
> > > data.pkg file.
> > > > >>>>
> > > > >>>> Cheers,
> > > > >>>>
> > > > >>>>
> > > > >>>> Dustin
> > > > >>>>
> > > > >>>> On Jul 31, 2014, at 3:53 PM, Andres Fernandez <
> > > andres.fernandez at nyu.edu> wrote:
> > > > >>>>
> > > > >>>>> Thank you!
> > > > >>>>> So building a code with the following packages should allow me
> to
> > > use external forcing correctly?
> > > > >>>>>
> > > > >>>>> # Packages
> > > > >>>>> &PACKAGES
> > > > >>>>> useOBCS=.TRUE.,
> > > > >>>>> usePtracers=.FALSE.,
> > > > >>>>> useRBCS=.FALSE.,
> > > > >>>>> useEXF=.TRUE.,
> > > > >>>>> #useLayers=.TRUE.,
> > > > >>>>> &
> > > > >>>>>
> > > > >>>>> Best,
> > > > >>>>> Andres
> > > > >>>>>
> > > > >>>>> Andres Fernandez
> > > > >>>>> Undergraduate Chemical Engineering
> > > > >>>>> New York University Abu Dhabi - 2015
> > > > >>>>> Mobile (USA): +1 646 717 2231
> > > > >>>>>
> > > > >>>>> *Think before printing. The environment is in our hands
> > > > >>>>>
> > > > >>>>>
> > > > >>>>>
> > > > >>>>> On Thu, Jul 31, 2014 at 12:08 PM, Jean-Michel Campin <
> > > jmc at ocean.mit.edu> wrote:
> > > > >>>>> Hi Andres,
> > > > >>>>>
> > > > >>>>> Since pkg/exf requires the use of calendar package (pkg/cal),
> > > > >>>>> this later (pkg/cal) is always compiled (MITgcm/pkg/pkg_depend)
> > > > >>>>> and used (in: model/src/packages_boot.F: IF (useEXF) useCAL =
> > > .TRUE.)
> > > > >>>>> anytime pkg/exf is compiled and used.
> > > > >>>>>
> > > > >>>>> Cheers,
> > > > >>>>> Jean-Michel
> > > > >>>>>
> > > > >>>>> On Thu, Jul 31, 2014 at 11:30:08AM -0400, Andres Fernandez
> wrote:
> > > > >>>>> > Dear MITgcm support,
> > > > >>>>> >
> > > > >>>>> > I have been trying to run the external forcing package; and I
> > > have yet to
> > > > >>>>> > succeed, but I was wondering if a reason why it is not
> working
> > > is because I
> > > > >>>>> > do not have the calendar package?
> > > > >>>>> >
> > > > >>>>> > Thank you,
> > > > >>>>> >
> > > > >>>>> > *Andres Fernandez*
> > > > >>>>> > Mobile (USA): +1 646 717 2231
> > > > >>>>> >
> > > > >>>>> > *Think before printing. The environment is in our hands
> > > > >>>>>
> > > > >>>>> > _______________________________________________
> > > > >>>>> > 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
> > > > >>>>>
> > > > >>>>> _______________________________________________
> > > > >>>>> 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
> > > > >>>>
> > > > >>>>
> > > > >>>> _______________________________________________
> > > > >>>> 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
> > > > >>>
> > > > >>>
> > > > >>> _______________________________________________
> > > > >>> 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
> > > > >>
> > > > >>
> > > > >> _______________________________________________
> > > > >> 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
> > > > >
> > > > >
> > > > >
> > >
> <STDOUT.0000.odt><DATA.odt><dotEfile.odt>_______________________________________________
> > > > > 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
> > > >
> > > > _______________________________________________
> > > > 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
> > >
>
> > _______________________________________________
> > 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mitgcm.org/pipermail/mitgcm-support/attachments/20140807/e434e166/attachment-0001.htm>
More information about the MITgcm-support
mailing list