I am trying to run the build script to compile CMAQ and I keep ending up with this errror
/usr/bin/ld: Warning: alignment 32 of symbol `bstate3_’ in /home/colethatcher/53_CMAQ/lib/x86_64/gcc/ioapi/lib/libioapi.a(initblk3.o) is smaller than 64 in pshut3.o
It still makes the executable but when I run the benchmark I get the warning
*** ERROR in INIT3/INITLOG3 ***
Error opening log file on unit 99
I/O STATUS = 17
File: CTM_LOG_000.v53_gcc_Bench_2016_12SE1_20160701
It is recommended (https://cjcoats.github.io/ioapi/AVAIL.html) that you build all libraries and models with consistent compile-flags. Go back, decide on a set of compile-flags (I recommend those from ioapi/Makeinclude.$BIN), and then build everything again from scratch.
Carlie J. Coats, Jr., Ph.D. cjcoats@email.unc.edu
Senior Software Engineer I/O API Author/Maintainer
Center for Environmental Modeling for Policy Development,
UNC Institute for the Environment www.ie.unc.edu
100 Europa Dr., Suite 490 Rm 4051 / Campus Box 1105 919.843.5951
Chapel Hill, NC 27599-1105 Fax 919.966.9920
If sizes of individual arrays or of COMMON blocks exceed 2GB on the x86_64 platforms, Intel ifort and icc will give you failures, with messages about relocation error s at link-time. The problem is that the default “memory model” doesn’t support huge arrays and huge code-sets properly. The “medium” memory model supports huge arrays, and the “medium” memory model supports both huge arrays and huge code-sets. To get around this, you will need to add
-mcmodel=medium -shared-intel
to your compile and link flags (for the medium model), and then recompile everything including libioapi.a and libnetcdf.a using these flags. Note that this generates a new binary type that should not be mixed with the default-model binaries. There is a new binary type BIN=Linux2_x86_64ifort_medium for this binary type, and a is a sample Makeinclude file for it, to demonstrate these flags:
Makeinclude.Linux2_x86_64ifort_medium
Other compilers and other non-Linux x86_64 platforms will have similar problems, but the solutions are compiler specific.
As far as I/O STATUS = 17 is concerned: IOSTAT errror-numbers are compiler specific, and sadly gfortran does not document theirs in a way that is google-able (one of the reasons I prefer other compilers; IMNHO, this documentation-failure excludes gfortran from the set of professional quality compilers.)
So i successfully recompiled everything using the flags you gave but it still shows the same error when i build the CMAQ executable. Is there anything else I could try? I think resolving this issue might resolve the benchmark case only executing till 23:55 on the first day
I was successfully able to compile everything with no errors after trying a few new options. the benchmark says the program completed successfully however it still stops at one day. I noticed in the run script the start and stop date listed only do one day. Am i supposed to change this so it will go for two days? There is no mention of it in the github tutorial on running the benchmark
Hi Liz, in connection to a similar time issue problem, I was wondering if it is possible to start CMAQ simulation at say 030000 hours of a certain day, especially as the IC starts at that hour and the BC is in 6hr intervals of 030000, 090000, 150000 and 210000?
Unless you are using CMAQv5.3, you should be able to start your CMAQ simulation at an hour other than 000000 as long as your run script is set up properly and all input files cover the time period you are modeling. The limitation in CMAQv5.3 was fixed with the release of CMAQv5.3.1 and is documented in the release notes.
As a general reminder, please only post in existing threads if the topic of your post is directly related to the thread title and existing discussion. If you cannot find any existing threads that meet this criterion, please open a new thread with a descriptive title so that the discussion is easier to find for other users.