[MITgcm-devel] MITgcm-cvs post from yunx

Mon Apr 5 17:10:58 EDT 2010

OK.

As requested, Yun Xu and I have removed the greenplanet-specific line from
linux_amd64_gfortran and instead added greenplanet-specific option files.

D.

On Mar 29, 2010, at 9:29 AM, Constantinos Evangelinos wrote:

> On Thursday 25 March 2010 09:30:09 pm you wrote:
> 
>> Constantinos, if it is an "unusual" location, that's a good thing.
>> It means that the likelihood of breaking someone else's setup is very, very
>> small. They would have to have the "correct" files in
>> /usr/include/netcdf-3 "and" the "wrong" files in
>> /sopt/netcdf/netcdf3-gcc-serial "and" use gfortran.
> 
> Yes but it would also mean that the next person would need to add their 
> unusual location to yours etc. It's not scalable. 
> 
>> There's a whole bunch of "unusual" things all over the code trying to make
>> sure that code runs as painlessly and automatically as possible on as many
>> platforms as possible.
> 
> But these fixes are platform-specific - not single machine-specific. 
> /usr/include/netcdf-3 is unfortunately or not a Linux-distro generic location. 
> /sopt/netcdf/netcdf3-gcc-serial is not.
> 
>> Your suggested solution is not quite adequate because it means that the
>> next potential MITgcm UCI user on greenplanet will stumble initially until
>> he discovers or is told about your email message.
> 
> Well - we can add a message for genmake2 to print if the NetCDF tests fail 
> that informs the user of the existence of the environment variables - just as 
> it does (anyway as there is no test) for PAPI/PCL/HPM/GSL etc.
> 
>> Can we add a linux_amd64_gfortran_greenplanet instead?
> 
> Sure you can - we have many of these. The problem is whether any new flags for 
> the next gfortran version (or revised NOPTFILES say) from the generic gfortran 
> optfile will make it as updates to that specific one.
> 
>> Would that be picked up automatically by genmake2?
> 
> We can do that as well if hostname returnes greenplanet. I would not do it. I 
> firmly believe either users learning what it is that they are doing or - if 
> they are not interested - in someone handing them a cheat-sheet (like God to 
> Moses :-).
> 
> Constantinos

On Mar 26, 2010, at 10:50 AM, Jean-Michel Campin wrote:

> Hi,
> 
> I don't have strong opinion on this, just that Constantinos' point
> make sense to me (i.e., not the best thing to have
> non standard path in a standard optfile like linux_amd64_gfortran,
> specially when it appears before the standard location).
> So, I would favor either Chris' way or setting those env 
> variables as Constantinos suggested.
> 
> But to come back to my point of using mitgcm-devel, we
> could have this discussion before committing the changes
> rather than after, specially if we end up removing the modif 
> (Constantinos suggestion).
> 
> Cheers,
> Jean-Michel
> 
> On Fri, Mar 26, 2010 at 11:43:38AM -0400, Chris Hill wrote:
>> My approach would be to create a
>> 
>>  linux_amd64_gfortran_greenplanet
>> 
>> optfile (assuming that greenplanet has stuff in some "non-standard"
>> locations). But I can't find Jean-Michel to check whether that is
>> my official policy!
>> 
>> Chris
>> 
>> On Fri, Mar 26, 2010 at 11:30 AM, Menemenlis, Dimitris (3248)
>> <Dimitris.Menemenlis at jpl.nasa.gov> wrote:
>>> Jean-Michel, this particular modif was checked in by me, not by Yun Xu, so you can blame me if you think it's a bad idea.  I have sent a separate email to Constantinos asking for a better solution than the one he suggests below, i.e., a solution that will not require the next MITgcm user on greenplanet to waste his time when attempting to get testreport to work if she or he happens not to be aware of this exchange.  D.
>>> 
>>> Dimitris Menemenlis <menemenlis at jpl.nasa.gov>
>>> Jet Propulsion Lab, California Institute of Technology
>>> MS 300-323, 4800 Oak Grove Dr, Pasadena CA 91109-8099, USA
>>> tel: 818-354-1656;  cell: 818-625-6498;  fax: 818-393-6720
>>> 
>>> On Mar 26, 2010, at 7:14 AM, Jean-Michel Campin wrote:
>>> 
>>>> Hi,
>>>> 
>>>> I take this opportunity to remember everyone that in the case
>>>> someone is not 100% sure of how/if/what things need to be checked-in
>>>> in the main MITgcm cvs repo, one can always send an email to
>>>> the mitgcm-devel list (this is the purpose of this list,
>>>> and this is also the reason why anyone who had the permission
>>>> to check-in thing should be reggister to this list).
>>>> 
>>>> Thanks,
>>>> Jean-Michel
>>>> 
>>>> On Thu, Mar 25, 2010 at 06:36:29PM -0400, Constantinos Evangelinos wrote:
>>>>>>> Modified Files:
>>>>>>>      linux_amd64_gfortran
>>>>>>> Log Message:
>>>>>>> This specifies location of correct netcdf libraries on machine
>>>>>>> greenplanet at UCI.  It needs to come before /usr/include/netcdf-3, which
>>>>>>> is also present but contains the wrong libraries.  There is a small
>>>>>>> possiblity this change will break netcdf libraries for machines that
>>>>>>> happen to have /sopt/netcdf/netcdf3-gcc-serial directory with wrong
>>>>>>> libraries.  Please let me know if someone runs into this situation and I
>>>>>>> will revert back and look for a different solution.
>>>>> 
>>>>> The solution is to set environment variables NETCDF_ROOT or NETCDF_HOME to the
>>>>> root directory of your netcdf installation or if they are separated set
>>>>> NETCDF_LIB or NETCDF_LIBDIR and NETCDF_INC or NETCDF_INCDIR respectively to
>>>>> the lib/include directories before calling genmake2 or testreport. Please do
>>>>> not hardcode unusual locations like the one above in a generic file. I would
>>>>> appreciate it if you could revert back to the previous version.
>>>>> 
>>>>> Constantinos
>>>>> --
>>>>> Dr. Constantinos Evangelinos
>>>>> Department of Earth, Atmospheric and Planetary Sciences
>>>>> Massachusetts Institute of Technology