Main menu

Navigation

CESM 1.2.1 build-namelist error I do not understand

9 posts / 0 new
Last post
rsheppar@...
CESM 1.2.1 build-namelist error I do not understand

Hello,

  I am building (or trying to build) CESM on our supercomputers for various faculty and researchers.  Since I am only building the framework, each user will need a unique workspace.  I designated:  <entry id="RUNDIR"   value="/N/dc2/scratch/$USER/cesm/run_dir"  /> in env_run.xml.

  However, my second running of cesm_setup generates the following message:

[rsheppar@h2 test1]$ ./cesm_setup
Use of qw(...) as parentheses is deprecated at ./cesm_setup line 252.
Macros script already created ...skipping
 Machine/Decomp/Pes configuration has already been done ...skipping
 Running preview_namelist script
Use of qw(...) as parentheses is deprecated at /N/dc2/projects/ray/quarry/cesm/cesm1_2_1/scripts/test1/Tools/ConfigCase.pm line 448.
Use of qw(...) as parentheses is deprecated at /N/dc2/projects/ray/quarry/cesm/cesm1_2_1/scripts/test1/Tools/ConfigCase.pm line 448.
Use of qw(...) as parentheses is deprecated at /N/dc2/projects/ray/quarry/cesm/cesm1_2_1/models/drv/bld/build-namelist line 781.
 infile is /N/dc2/projects/ray/quarry/cesm/cesm1_2_1/scripts/test1/Buildconf/cplconf/cesm_namelist
** build-namelist - CCSM inputdata root is not a directory: "/N/dc2/scratch/$USER/cesm/din_input" **
ERROR: cpl.buildnml.csh failed
ERROR: /N/dc2/projects/ray/quarry/cesm/cesm1_2_1/scripts/test1/preview_namelists failed: 25344
*****************

That does not make sense to me because it IS a directory (nothing is in it at the moment though):

[rsheppar@h2 test1]$ ls -l /N/dc2/scratch/$USER/cesm/din_input
total 0

I readily admit I am learning this as I go, but I can't understand what I could be doing wrong.  I would appreciate any pointers to my trouble.

Thanks,

Ray

santos

It looks like this check on DIN_LOC_ROOT is done before substitution is done on the variables in the XML. This is probably because we assume that everyone on a system will share a single inputdata directory for their files. You will have to replace "$USER" with a specific name in your DIN_LOC_ROOT.

Sean Patrick Santos

CESM Software Engineering Group

rsheppar@...

Thanks Santos,

  Between the Cray and the IBM, we have about 3000 users.  Geology and Geography alone have a couple hundred. That is not counting various grant collaborations that also use the systems.  Of course, only a small fraction of that number are researching climate science.  However, they really don't all know or collaborate with each other.  That makes placing a "specific name" untenable.  I was hoping there would be some set up file somewhere where a command analagous to "import env $USER" could be placed.  Thanks again.

Ray

santos

I believe that you can work around this by editing the script at models/drv/bld/build-namelist. Note the following block:

 

my $DIN_LOC_ROOT = $xmlvars{'DIN_LOC_ROOT'};
(-d $DIN_LOC_ROOT)  or  die <<"EOF";
** $ProgName - CCSM inputdata root is not a directory: \"$DIN_LOC_ROOT\" **
EOF
if ($print>=2) { print "CESM inputdata root directory: $DIN_LOC_ROOT$eol"; }

# Note - $USER is not in the config_defintion.xml file - it is only in the environment
$xmlvars{'USER'} = $ENV{'USER'};
foreach my $attr (keys %xmlvars) {
    if ( $xmlvars{$attr} =~ m/\$/ ) {$xmlvars{$attr} = expand_env_xml($xmlvars{$attr});}
    if ( $xmlvars{$attr} =~ m/\$/ ) {$xmlvars{$attr} = expand_env_xml($xmlvars{$attr});}
    if ( $xmlvars{$attr} =~ m/\$/ ) {$xmlvars{$attr} = expand_env_xml($xmlvars{$attr});}
}

 

If you take all of the lines I've quoted after the "Note" comment, and place them before all the lines I've quoted mentioning "DIN_LOC_ROOT", I believe that that will be sufficient.

That said, if you have many users using the same system (or filesystem) we strongly discourage people from setting things up so that every user has their own DIN_LOC_ROOT. If you have more than a couple of users on a system, many people will end up with identical versions of files, which can be a huge waste of space. On most of the machines supported by NCAR, we have requested for system administrators to create a shared space to store input data for CESM users. This is a much more efficient solution than having each user create their own inputdata directory, and it is more fair than putting DIN_LOC_ROOT in the directory of one specific user.

So I would encourage you to get a group or project space on the filesystem for CESM users, at least to handle the standard data sets. If users have their own modified data sets, they can keep these in their own directories. DIN_LOC_ROOT is intended for commonly used files; not every inputdata set has to be in that directory in a given run.

Sean Patrick Santos

CESM Software Engineering Group

rsheppar@...

Thanks a lot!

  I had been playing with Perl'isms and C-Shell commands in various places.  Back in the days of Teragrid, we had shared project spaces.  The management did away with that model.  Now there is just a farm of three and a half petabytes of direrctory space with no user quotas.  The various depts/groups can request system support. If it is approved, it usually lands in my merry group.

  Unlike actual installs like AM2 or AM3 (which I am recently learning as well), I think the best I can do for them is give them a standardized machine definition and then let them create and run their experiments in a standard scratch location we give them.  Then they can move whatever is important to a more protected location by simply swapping "scratch" with "home" or "project."    I only expect about 20 to 30 total users from two departments and a new NASA grant.  But, Geology does not normally interact with Geography and I am sure the NASA folks (who first asked for the support) would rather keep their own queues.

  So, thanks again. Sorry for dumping the whole scene, but I am likely to ask more naive questions again in the future.

Ray

jedwards

I really think that you need to consider setting up a shared inputdata directory in your machine definition.   You don't want 30 copies of that directory floating around on your system and it's basically read-only data so it won't matter who is using it, there won't be any conflict between different users.   

CESM Software Engineer

rsheppar@...

I guess I need to spend more time reading the manuals. I have only been looking in the build sections. So all three projects would be using the exact same inputs for each user?  That is very unusual in my experience.  The machines went down for operating system upgrades.  You are right though.  If the inputs are identical for all users, there is no need to make users provide them.  I guess I need to do some reading to see why they don't get identical outputs with the same inputs.  Thanks!

Ray

 

Ray

jedwards

Inputs depend on a number of factors in the simulation and are not the same for each simulation, however there is a great deal of overlap and much of the input data is reused in multiple simulations.   The CESM will download and add data that it needs to the inputdata directory for each simulation unless it's already there.   That used to be a slow and error prone process but it has improved in recent years.  If you want to try having each user have thier own inputdata directory we would love some feedback on your experience - maybe our opinion on this is based on outdated experience.   

CESM Software Engineer

rsheppar@...

Thanks!

  That actually makes more sense to me.  I had the SysAdmins give each physical group a unique UNIX group.  I can monitor their aggregate usage that way.  If each user only consumes about a terabyte, then 20 users (we all know the bosses seldom run themselves) would only be about half a percent of the system.  That is not too bad for us and they are expecting to grow out the disk system further later in the year.  While this discussion has been about the inputs specifically, I also had the same issues with rundir(?) too. Importing the logname/user variable should fix both.  As you likely know, in academia, they like to keep their projects private.  We like giving them their own little cubby holes.  This need will become an even greater need if someone wants to run CESM on JetStream once it comes online.  Thanks to everyone for the support!

Ray

Ray

Log in or register to post comments

Who's new

  • jwolff
  • tinna.gunnarsdo...
  • sarthak2235@...
  • eolivares@...
  • shubham.gandhi@...