[MITgcm-support] Suggestions for making MITgcm accessible

Martin Losch Martin.Losch at awi.de
Thu Jun 7 06:23:13 EDT 2007


Hi Bill,

since no-one has answered you yet, I will, although I may not  
represent the typical "MITgcm enthusiast".

First of all, thanks for your suggestion.

The general idea of the MITgcm portability is that it should compile  
and run on basically any computer platform that runs some sort of  
UNIX-like OS (including cygwin, for example). In order to ensure  
this, the "distribution"/cvs-repository provides many different  
"build_options" files. The build_options file that you specify when  
you do the genmake step is  meant to be the only place where platform  
and compiler dependent customization should take place. If there are  
actually platform dependent bits of code in the model we always try  
to fix them. This "philosphy" works fairly well for most single cpu  
and parallel computer architectures, although I am now struggling  
with a vector computer for which the MITgcm is only efficient if the  
horizontal domain size is fairly large (because the code generally  
excludes vectorization in the vertical dimension, and that's not  
likely to change).

The verification experiments are used to test the code on a daily  
basis to make sure that new developments don't break it. But they are  
also meant to be starting point for someone starting a new project.  
However, since the code is in Fortan77 with static (and hard coded)  
array sizes (in the file SIZE.h), pre-compiled binaries work only for  
the specific experiments and the specific array size. In other words  
pre-compiled binaries do not make too much sense.

What does make sense, though, is to provide build options files for  
your cases (there are many examples in the repository, even one that  
is called sun4u_amd64_f77_awi, which was used to build the model on a  
particular machine we had in my institute, sorry, that I haven't  
pointed that our earlier). If you give your files appropriate names  
according to the file name patterns in the tools/build_options  
directory, that is something like this:
$ostype_$processortype_$compiler_$machinename (if it's *really*  
generic without the machine name)
and maybe put some useful comments into it, we will happily include  
them in the repository and anyone using a comparable platform can use  
them (or creating their own based on your file(s)).

Martin

On 5 Jun 2007, at 22:25, william aiken wrote:

> Dear support alias,
>
>   I was able to provide a build_option file that enables the 64 bit
> Solaris x86 version of MITgcm (checkpoints58.tar) to build  
> successfully.
>
> The single threaded test cases run to completion and I am working  
> on the
> multithreaded and MPI cases.
>
> I would like to make an MITgcm binary available on network.com so that
> the community can benefit from a readily available binary version  
> of the
> this app. I followed the instructions to build mitgcmuv for each
> verification case, and I noticed that there is some variation in the
> binaries that I built. If I understand correctly, these different
> versions of mitgcmuv are configured to address different types of
> current modeling.
>
> What I am trying to determine is whether I should put all 29 (more or
> less) different versions of mitgcmuv on network.com. Does it make  
> sense
> to do this?
>
> It appears there are two communities of MITgcm enthusiasts - those  
> that
> extend the model and put back new source code, and those that download
> MITgcm, build one or more mitgcmuv binaries, and use the  
> application as
> it exists without modifying it.
>
>  Is this a reasonable assessment, or is it true that everyone in the
> MITgcm community is in the first category? If so, then making pre- 
> built
> binaries available to the general public probably doesn't make much  
> sense.
>
> Please let me know which model more accurately depicts the MITgcm user
> community, and if it does serve a purpose to build one or more  
> MITgcmuv
> binaries, should all the verification versions be built or only a  
> subset?
>
> Thanks in advance for your input,
>
> Regards,
>
> Bill
>
>
> -- 
> William Aiken          Sun Microsystems, Inc.
> Phone: 781.442.3312    Market Development Engineering
> FAX: 781.442.1678      One Network Drive UBUR01-204
>                        Burlington, Massachusetts 01803
>
> _______________________________________________
> MITgcm-support mailing list
> MITgcm-support at mitgcm.org
> http://mitgcm.org/mailman/listinfo/mitgcm-support




More information about the MITgcm-support mailing list