[MITgcm-support] adjoint compilation on 64bit system

[Patrick Heimbach]

Hi Martin,

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.

-Patrick



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 
> problematic?
> 
> Martin
> 
> 


--------------------------------------------------------
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
http://www.mit.edu/~heimbach/                        USA