[MITgcm-support] adjoint compilation on 64bit system
heimbach at MIT.EDU
Thu Feb 24 11:55:18 EST 2005
control and gradient __VECTORS__ are the only files that
aren't subject to direct access I/O, but rather sequential
(reason is that there isn't a well-defined record length).
That makes them somewhat hard to port across platforms.
Potential issues then are:
o big vs. little endian:
your optfile for ifc uses the MITgcm '-D_BYTESWAPIO'
your optfile for amd uses the compiler flag '-byteswapio'
The former affects only MDSIO routines (thus NOT ecco_c*)
the latter affects all I/O
o COS block size in sequential binary
We think they should be same size between the two,
so shouldn't be an issue
o word length vs. byte rec. length
o Last but not least:
Did you make sure, your ctrlprec (in ctrl.h) agree
across both platforms (I am guessing you use ctrlprec=32 ?).
Could you regenerate your ecco_c* under ifc using the
compiler options '-assume byterecl -convert big_endian'
(and have '-DBYTERECLEN=4')?
Then everything should be consistent with your
AMD compiler config.
I have ported a control vector from an O3K to an Altix
recently, and it worked, after making sure that all these
issues are consistent.
Quoting Martin Losch <mlosch at awi-bremerhaven.de>:
> Hi Patrick,
> my error log was not complete, as usual. In fact, the problems are not
> limited to adconvective_adjustments: Many routines have the similar
> problem, i have not found a pattern, yet. (all error messages of the
> link step are attached in make.log fyi).
> Still another question, (maybe more urgent, as the flag -fpic seems to
> solve my problem):
> I need to switch platforms in the middle of an optimization, from a
> linux_ia32 system with ifc to an linux_amd64 system with pgf77. after
> recompiling mitgcmuv_ad I thought, all i need are the current
> ecco_ctrl*opt???? ecco_cost*opt???? files to extract the control
> vector, but when reading the new control vector, there is a problem:
> mitgcmuv_ad tried to read past the end of the file. Is that supposed to
> work, or is that a problem that I cannot fix? (this is not an exclusive
> "or", is it? (o:) I have not even tried reading OPWARMD and OPWARMI
> with a optim.x on the amd64 machine, that's probably even more
Patrick Heimbach Massachusetts Institute of Technology
FON: +1/617/253-5259 EAPS, Room 54-1518
FAX: +1/617/253-4464 77 Massachusetts Avenue
mailto:heimbach at mit.edu Cambridge MA 02139
More information about the MITgcm-support