Users (#3) - [AGRIF] Compiling with ORCA2_LIM3_PISCES using intel (#32) - Message List

[AGRIF] Compiling with ORCA2_LIM3_PISCES using intel
 solved

Hello,

I’m trying to run NEMO with the ORCA2_LIM3_PISCES reference configuration, however, I run into a problem when compiling NEMO.

So, first, I checkout the trunk NEMO, cd to the CONFIG folder and then run makenemo (I've already downloaded and built XIOS v2 r990).

svn --username 'mbareford' co http://forge.ipsl.jussieu.fr/nemo/svn/trunk/NEMOGCM
cd ./NEMOGCM/CONFIG
./makenemo -r ORCA2_LIM3_PISCES -n AGRIF -m XC_ARCHER_INTEL add_key 'key_agrif'

The error is caused by the fact that nn_limadv_ord is not defined.

./NEMOGCM/CONFIG/AGRIF/BLD/ppsrc/nemo/limadv_umx.f90(111): error #6404: This name does not have a type, and must have an explicit type.   [NN_LIMADV_ORD]
      SELECT CASE( nn_limadv_ord )

This variable is defined as an integer in ./NEMOGCM/NEMO/LIM_SRC_3/ice.F90, but for some reason the ice.f90 file that exists in ./NEMOGCM/CONFIG/AGRIF/BLD/ppsrc/nemo/ is just an empty module, i.e., it contains no declarations.

Please could you tell me what I need to do to get NEMO to compile.

Thanks, Michael

Tree View Flat View (newer first) Flat View (older first)
  • Message #40

    Below is the reply from Claire to my original email.

    First of all, we need to agree that you’re working with nemo_3_6_STABLE release? This is not what your svn checkout command shows: you seem to have extracted NEMO trunk, which is not at all a stable version, not even a version: it is ongoing development work. I first suggest you restart from scratch, following: https://forge.ipsl.jussieu.fr/nemo/wiki/Users/ and more specifically https://forge.ipsl.jussieu.fr/nemo/wiki/Users/ModelInstall#a1.ExtracttheNEMOcode

    In the second step, as seen from the copy of your makenemo command, I see strange quotes around key_agrif. Could you check that the key_agrif is indeed in the CONFIG/cpp_AGRIF.fcm text file?

    For future questions, in order to get a quick and complete answer, please use the forums: https://forge.ipsl.jussieu.fr/nemo/discussion Hope this helps Claire for NEMO System Team

  • Message #41

    Hi Claire,

    Apologies for the strange quotes around key_agrif, but don't worry, those characters were introduced by my email editor. The compile command I've been running as normal quotes.

    ./makenemo -r ORCA2_LIM3_PISCES -n AGRIF -m XC_ARCHER_INTEL add_key 'key_agrif'
    

    However, the ./AGRIF/cpp_AGRIF.fcm file is empty, it has zero length.

    At first I did check out the nemo source from the stable branch, e.g.,

    svn --username 'mbareford' co -r 6721 http://forge.ipsl.jussieu.fr/nemo/svn/branches/2015/nemo_v3_6_STABLE/NEMOGCM
    

    The problem here though is that ORCA2_LIM3_PISCES does not appear in the list of reference configurations. This is the one that uses AGRIF as shown on https://forge.ipsl.jussieu.fr/nemo/wiki/Users/ReferenceConfigurations.

    Since then I've done the following.

    svn --username 'mbareford' co http://forge.ipsl.jussieu.fr/nemo/svn/branches/2015/nemo_v3_6_STABLE/NEMOGCM
    

    This checks out r9301. Next, I copied the ORCA2_LIM3_PISCES folder from the trunk CONFIG directory to the v3_6_STABLE r9301 CONFIG directory. Then I reran the makenemo command as above.

    Everything compiled and linked successfully once I had also copied ./CONFIG/ORCA2_LIM3_PISCES/EXP00 to ./CONFIG/AGRIF. The linker required that ./CONFIG/AGRIF/EXP00 existed before it could create the opa link.

    I will shortly run the nemo code over 24 cores (and XIOS on 2 cores) and let you know how I get on.

    Thanks, Michael

  • Message #42

    Looks indeed a little better, and the confusion comes also from the wiki pages.

    Indeed, looking at the CONFIG directory, you have mainly 2 global configurations:

    • ORCA2_LIM_PISCES using LIM2 (i.e. not LIM3) with key_lim2 activated
    • ORCA2_LIM using LIM3 (i.e. not LIM2) with key_lim3 activated

    So that if you want to build a configuration using global 2° with LIM3 and PISCES, you should do

    ./makenemo -r ORCA2_LIM_PISCES -n AGRIF -m XC_ARCHER_INTEL add_key 'key_agrif key_lim3' del_key 'key_lim2'
    

    The argument of -r in this line must be an existing Reference configuration

    At this point, in your CONFIG/AGRIF directory, you should check which sea ice model (key_lim2 or key_lim3) is indeed active in your AGRIF/cpp_AGRIF.fcm file

  • Message #43

    Ok, I've tried the new make command.

    ./makenemo -r ORCA2_LIM_PISCES -n AGRIF -m XC_ARCHER_INTEL add_key 'key_agrif key_lim3' del_key 'key_lim2'
    

    It creates a ./AGRIF/cpp_AGRIF.fcm file that contains the following keys.

    bld::tool::fppkeys key_trabbl  key_dynspg_flt key_diaeiv key_ldfslp key_traldf_c2d key_traldf_eiv key_dynldf_c3d key_zdftke key_zdfddm key_zdftmx key_top key_pisces key_iomput key_mpp_mpi key_agrif key_lim3
    

    So it looks like the add_key and del_key options worked as expected.

    Unfortunately, the build then goes on to fail with this error.

    gmake: *** No rule to make target `ice.f90', needed by `iom.f90'.  Stop.
    
  • Message #44

    Even though I've replaced key_lim2 with key_lim3, the ORCA2_LIM_PISCES reference config will still be using lim2 under the hood.

    And that's why it can't fine ice.f90, since that file is located in ./NEMO/LIM_SRC_3/.

    I guess the cfg.txt file will need to be changed such that ORCA2_LIM_PISCES is associated with LIM_SRC_3. However, it looks like there are other LIM2 dependencies: e.g., see ./CONFIG/ORCA2_LIM_PISCES/IGCM00/config.card.

    Rejigging the ORCA2_LIM_PISCES config so that it uses LIM3 might be too much work here: all I want to do is have an AGRIF test case that can run on a few ARCHER nodes (24 cores per node) and produce an ocean temperature map at the end of the simulation.

    `

  • Message #45

    Hi Michael,

    I think there is a bit of a confusion between code branches and reference configurations to use to build an AGRIF config.

    There is probably a bug as you should be able to compile from ORCA2_LIM_PISCES but it had probably not being tested. But from the release of 3.6 version of NEMO, it has been defined to use ORCA2_LIM as reference configuration with key_agrif:

    ./makenemo -r ORCA2_LIM -n AGRIF add_key 'key_agrif'
    

    And this should work as expected.

    Nicolas

  • Message #46

    Thanks Nicolas, the ORCA2_LIM compiles with key_agrif. I linked the compilation to xios-v1 r703 in order to be compatible with the xml files in ORCA2_LIM.

    I would like to run the code now, but first, I need the appropriate config/netcdf files. Is it ok to use the ones in this tar file, ORCA2_LIM_nemo_v3.6.tar? There's a link to that tar file on this page, https://forge.ipsl.jussieu.fr/nemo/wiki/Users/ReferenceConfigurations/ORCA2_LIM3_PISCES; not sure if it's compatible with ORCA2_LIM.

    I have in fact unpacked ORCA2_LIM_nemo_v3.6.tar within ./CONFIG/AGRIF/EXP00 then run nemo like so.

    aprun -n 24 -N 24 $NEMO_PATH/nemo.exe
    

    Unfortunately, the run seg faulted, producing a truncated ocean.output file. There were no errors reported within ocean.output.

  • Message #47

    Thanks Nicolas, the ORCA2_LIM compiles with key_agrif. I linked the compilation to xios-v1 r703 in order to be compatible with the xml files in ORCA2_LIM.

    I would like to run the code now, but first, I need the appropriate config/netcdf files. Is it ok to use the ones in this tar file, ORCA2_LIM_nemo_v3.6.tar? There's a link to that tar file on this page, https://forge.ipsl.jussieu.fr/nemo/wiki/Users/ReferenceConfigurations/ORCA2_LIM3_PISCES; not sure if it's compatible with ORCA2_LIM.

    Yeah, ORCA2_LIM_nemo_v3.6.tar is the only archive needed for almost all reference configurations.

    I have in fact unpacked ORCA2_LIM_nemo_v3.6.tar within ./CONFIG/AGRIF/EXP00 then run nemo like so.

    aprun -n 24 -N 24 $NEMO_PATH/nemo.exe
    

    Unfortunately, the run seg faulted, producing a truncated ocean.output file. There were no errors reported within ocean.output.

    Could you give us a bit more informations? What does the ocean.output end up on?

  • Message #48

    The last two lines of ocean.output follow.

    rot_rep : geographic ←→ stretched

    ~ coordinate transformation

    I've also attached the whole file to this thread.

    Thanks, Michael

  • Message #49

    Hi Nicolas/Clevy/Clair?,

    Have you been able to learn anything from the ocean.output file?

    Regards, Michael

  • Message #50

    Just to let you know, I've setup a test case based on ORCA2_LIM that was compiled without the agrif key. Below is the compile command.

    ./makenemo -r ORCA2_LIM -n ORCA2_INTEL -m XC_ARCHER_INTEL
    

    After populating the ./CONFIG/ORCA2_INTEL/EXP00 with files archived in ORCA2_LIM_nemo_v3.6.tar, I submitted a job that ran on one ARCHER node.

    aprun -n 24 -N 24 $NEMO_PATH/nemo.exe
    

    This short test appears to have run successfully. I've also attached the output file, see ocean_without_agrif.output. So, the reason why the agrif test case doesn't run could be due to the code included by the key_agrif preprocessor constant.

    Michael

  • Message #51

    Actually, I can't seem to add a second attachment to this thread. So, that attachment that is there, is the ocean output file produced by the agrif test case that currently fails.

    Michael

  • Message #53

    Actually, I can't seem to add a second attachment to this thread. So, that attachment that is there, is the ocean output file produced by the agrif test case that currently fails.

    Michael

    Actually there is a bug due to a change in the Apache configuration that prevents the attachment uploading.
    It should be fixed soon.

  • Message #54

    Hello,

    I've decided it would be best to end this thread.
    My problem has moved from a compilation issue to a runtime problem (i.e., seq faulting), so I've posted a new message to the forum.

    Some progress has been made too.

    Previously, NEMO was being compiled with "-O3", I've changed this to "-g -O0": the code now runs for longer before seg faulting.

    In addition, I've noticed that the run produces a second output file called "1_ocean.output". That output file contains an error message which is given at the top of my new post.

    Regards, Michael

  • Message #55

    Hello Mickael,

    Thanks for trying to manage it on your own.
    The successful attempt of reducing the optimization tends to show something is still hidden behind.

    I'm not sure it was worth a dedicated topic outside this one but I will try to get a look at it.

    Regards,
    Nicolas

Tree View Flat View (newer first) Flat View (older first)

Attachments (1)

Download all attachments as: .zip