[MITgcm-support] problem running optim.x

Charlotte Breitkreuz cbreitkreuz at marum.de
Thu Jul 28 03:25:41 EDT 2016


Hello again,

just in case someone is interested or has the same problem:

I fixed the problem by adding some compiler options when compiling lsopt 
and optim. More explicitely, I added
FFLAGS          = -fconvert=big-endian -fimplicit-none .

Cheers,
Charlotte



On 07/26/2016 05:17 PM, Charlotte Breitkreuz wrote:
> Hello everybody,
>
> I recently started to work with the adjoint of the MITgcm and having a 
> problem using optim.x.
> The problem comes up in a configuration similar to 
> ./verification/global_ocean.cs32x15, but also in the unchanged(!) 
> ./verification/tutorial_global_ocean_optim.
>
> Compiling and running mitgcmuv_ad as described in the manual in 
> section 3.18 works fine. Compiling optim.x also works fine.
> Then when I try to use optim.x after running mitgcmuv_ad I get the 
> following message:
>
> ----------------------------------------------------------------------------------
>   ==================================================
>   Large Scale Optimization with off-line capability.
>   ==================================================
>
>                  Version 2.1.0
>
>   OPTIM_NUMBMOD: Control options have been read.
>   OPTIM_NUMBMOD: Minimization options have been read.
>  pathei-lsopt in optim_readdata
>
>   OPTIM_READDATA: Reading control vector
>              for optimization cycle:            0
>
>  dfile= ecco_ctrl
>  yctrlid= MIT_CE_000
>  nopt=            0
>  fname= ecco_ctrl_MIT_CE_000.opt0000
>  opened file ecco_ctrl_MIT_CE_000.opt0000
> At line 1717 of file optim_readdata.f (unit = 20, file = 
> 'ecco_ctrl_MIT_CE_000.opt0000')
> Fortran runtime error: End of file
>
> -----------------------------------------------------------------------------------
>
> The lines in optim_readdata.f before the error look like this:
>
> -----------------------------------------------------------------------
>       write(fname(1:128),'(4a,i4.4)')
>      &     dfile,'_',yctrlid(1:10),'.opt', nopt
>
>       open( funit, file   = fname,
>      &     status = 'old',
>      &     form   = 'unformatted',
>      &     access = 'sequential'   )
>       print*, 'opened file ', fname
>
> c--   Read the header.
>       read( funit ) nvartype
>       read( funit ) nvarlength <-- 1717
> -----------------------------------------------------------------
>
> So the file 'ecco_ctrl_MIT_CE_000.opt0000' is opened and the first 
> value nvartype is actually read, but then the file does not contain a 
> second one.
> Possibly, someone else can reproduce this error just compiling and 
> running mitgcmuv_ad in verification/tutorial_global_oce_optim/code_ad 
> and input_ad, respectively, and then looking at the file 
> 'ecco_ctrl_MIT_CE_000.opt0000'.
>
>
> I guess that this is not a problem of optim.x but more a problem of 
> how the ecco_ctrl file is written by mitgcmuv_ad. This is done in 
> ctrl_pack.F, but everything looks fine there..
>
> I work with checkpoint 65v, use the adjoint_options file which is 
> located in the ./tutorial_global_ocean_optim/code_ad folder. My 
> compiler for the mitgcmuv_ad is  mpif77.
>
> If someone else does not encounter this problem, could it be a problem 
> of my compiler or my machine?
>
> Any help is appreciated! Let me know if you need any more information.
>
> Thanks a lot!
>
> Regards,
> Charlotte
>
>
> -- 
> *Charlotte Breitkreuz*, M. Sc. Technomathematik
> PhD Student
> Research Group 'Geosystem Modeling'
>
> *MARUM* - Center for Marine Environmental Sciences, University of Bremen
> *FB5* - Department of Geosciences, University of Bremen
> Klagenfurter Straße 2
> 28359 Bremen, Germany
> Room 5420
>
> Tel: +49(0)421 - 218 65448
>

-- 
*Charlotte Breitkreuz*, M. Sc. Technomathematik
PhD Student
Research Group 'Geosystem Modeling'

*MARUM* - Center for Marine Environmental Sciences, University of Bremen
*FB5* - Department of Geosciences, University of Bremen
Klagenfurter Straße 2
28359 Bremen, Germany
Room 5420

Tel: +49(0)421 - 218 65448

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mitgcm.org/pipermail/mitgcm-support/attachments/20160728/767dd765/attachment.htm>


More information about the MITgcm-support mailing list