Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

An error occurred when building the MPAS. #695

Closed
zhangjiang-dev opened this issue Sep 15, 2020 · 21 comments
Closed

An error occurred when building the MPAS. #695

zhangjiang-dev opened this issue Sep 15, 2020 · 21 comments

Comments

@zhangjiang-dev
Copy link

when i use ‘make gfortran CORE=ocean’ this command to build mpas,but the program occurred an error,as follows.
the directory of pio installation is '/usr/local/lib,/usr/local/include',How should I specify the environment variable of pio?
thanks !

Checking for a usable PIO library...
************ ERROR ************
Failed to compile a PIO test program
Please ensure the PIO environment variable is set to the PIO installation directory
************ ERROR ************
make[1]: *** [pio_test] Error 1
make[1]: Leaving directory `/opt/mpas/MPAS-Model-master'
make: *** [gfortran] Error 2

@xylar
Copy link
Collaborator

xylar commented Sep 15, 2020

@zhangjiang-dev, we would need to know considerably more about where you're trying to build the model to be very helpful in responding to your question. As a starting point, though, I'm providing a PDF of the instructions we share with one another internally in the group to get MPAS-Ocean building on various systems we use.

Please see how far you can get with those suggestions. If you are still having trouble, please provide us with quite a bit more details on what operating system, machine, compilers, MPI, etc. etc. you are using and we may be able to help you as we have time. It would also be helpful for us to know how you plan to use the code.

Keep in mind, though, that we are coming up against a major deadline for our code release and our time may be very limited at the moment.

ECG-MPASTestingandMachine-specificInstructions-150920-1448.pdf

@philipwjones
Copy link
Contributor

@zhangjiang-dev It's probably as easy as setting the PIO environment variable in your case to /usr/local
But please do read the doc Xylar sent too. That should help alleviate potential future issues.

@zhangjiang-dev
Copy link
Author

Thank you for the documentation!But it didn't solve my problem.
Before building mpas-ocean,If my pio installation path is /home/hpc/pio,How should I specify the pio environment variable?
Importantly, what is the name of the pio environment variable?
The environment variable solves, so my problem solves.
By the way, can you provide a copy of the installation documents and materials about mpas - ocean?
Thanks a lot!

@zhangjiang-dev
Copy link
Author

I set the PIO environment variables as follows:
export PIO=/home/hpc/pio
But it still reports the following error:
make[1]: Entering directory `/opt/mpas/MPAS-Model-master'
Checking for a usable PIO library...
************ ERROR ************
Failed to compile a PIO test program
Please ensure the PIO environment variable is set to the PIO installation directory
************ ERROR ************

@philipwjones
Copy link
Contributor

Looks correct, assuming the pio installation is good. As Xylar says, to go any further, we need a lot more info about where you're running, what compilers you're using, what projects you're working on, etc...

@zhangjiang-dev
Copy link
Author

Before building mpas_ocean,i have installed the following dependency packages:
gcc 9.1.0、openmpi 3.1.0、netCDF 4.1.3、parallel-netCDF 1.3.1、netCDF-fortran 4.4.4、PIO 2.5.1
The version of mpas-ocean is master. You can download it from the following link:
https://github.com/MPAS-Dev/MPAS-Model.git

Could you provide me with a copy of the mpas - ocean executable that you compiled? The file format is nc.
It is similar to the following file format:
o.x1.15km.0019-01-01_00.00.00.nc

Thanke you very very much!

@zhangjiang-dev
Copy link
Author

My machine environment is as follows:
linux x86
os:RedHat 7.4

@xylar
Copy link
Collaborator

xylar commented Sep 17, 2020

@zhangjiang-dev, I think you may just need to set this additional environment variable:

export USE_PIO2=true

With our current development branch (ocean/develop), there is more helpful output when compilation fails because you have provided PIO2 but have not specified USE_PIO2 but that may be new since the 6.0 release on master.

Could you provide me with a copy of the mpas - ocean executable that you compiled?

We do not currently provide compiled binaries. None of our collaborators so far is on a generic enough system that this would be useful. So we only support building from source code.

Please keep in mind that, while this is an open source project, we have quite limited time for supporting projects that are not part of our collaborations funded by the US Department of Energy or other partner agencies.

This is, in part, why it would be helpful to know a little more about what you are hoping to accomplish with MPAS-Ocean. We may be able to quickly tell you if it is likely to be easy for you to get started on your own (once the code compiles) or whether it is a project that might require a lot of expertise from MPAS-Ocean developers that we are unlikely to be able to provide at this time.

@afernandezody
Copy link

Hello,
I'm chiming in as I'm facing the same problem (albeit with atmosphere rather than ocean). Looking at the Makefile, it seems like the PIO test is trying to compile either pio1.f90 or pio2.f90. However, these files don't seem to be in the PIO directory (or anywhere else); the only f90 files are pio-2.5.2/tests/fncint/ftst_pio.f90 and /pio-2.5.2/tests/fncint/ftst_pio_orig.f90. My PIO installation is 2.5.2. Thanks.

@philipwjones
Copy link
Contributor

philipwjones commented Sep 21, 2020

If you look at that line, it actually generates an extremely simple file to compile.

@mgduda
Copy link
Contributor

mgduda commented Sep 21, 2020

@afernandezody If you're seeing the same issue with the atmosphere core, we have a support forum for MPAS-Atmosphere where you could post your question: https://forum.mmm.ucar.edu/ . Just be sure to post in the correct section of the forum.

As @philipwjones said, though, the test program is generated by the top-level Makefile.

@afernandezody
Copy link

Hi @philipwjones,
I see what you mean but are these files supposed to be written in the subdirectory? Thanks.

@philipwjones
Copy link
Contributor

@afernandezody it is removed immediately after writing the pio message (see rm -rf pio[12].f90). Note that this is also how tools like CMake look for a working MPI, etc.

@philipwjones
Copy link
Contributor

BTW, note that when it tries to build this simple code, it redirects output to /dev/null I've never tried to see what happens if you remove that redirection and see what happens - might get some additional info on why it's failing.

@afernandezody
Copy link

You're right, the script now makes sense (once I paid attention to all the details). The problem seems to be that the configuration assumes x86_64 architecture whereas the system is arm-powered.

@afernandezody
Copy link

Hi @philipwjones, I was able to fix the previous issue by fitting the flags to arm architecture. I did this manually, which is not an optimal method, so maybe this could be a future enhancement (I don't know about the ramifications of it and you can weight its convenience). However, I'm getting a new error:
Fatal Error: Cannot open module file 'pio.mod' for reading at (1) even though $(FCINCLUDES) seems to be pointing to the headers correctly (-I/PATH-TO/pio-2.5.2/include -I/opt/netcdf/include). Let me know if you want me to open a separate thread.

@philipwjones
Copy link
Contributor

@afernandezody As @mgduda suggests above, the atmosphere folks maintain a support forum and that's probably a better path for you. I only responded earlier because I've messed with this before and happened to know the answer to your initial questions. For both of these issues reported here, there appears to be something specific to your machine and environment or maybe the pio build (eg did it build the fortran interfaces correctly and drop the mod file in the right place?). Anyway, you'll probably get a faster response there.

@afernandezody
Copy link

Hi @philipwjones and @mgduda,
I'm familiar with the forum because of WRF. I'm working with an alpha-phase system and have almost run out of time for testing. It seems to be a very specific problem with the system as you mentioned so I'll just try to tweak a couple of things in the configuration as time permits. Thanks.

@mkstratos
Copy link

I've run into a similar problem in nightly testing on the landice/develop branch. It seems to be caused by a recent change to PIO NCAR/ParallelIO#1659 which writes a libpio.settings summary file to the PIO installation's lib directory. Then the MPAS Makefile here

ifneq ($(wildcard $(PIO_LIB)/libpio\.*), )
detects this as PIO 1 rather than 2 I believe?

My quick fix locally is to replace that line with:
ifneq ($(wildcard $(PIO_LIB)/libpio\.*), $(wildcard $(PIO_LIB)/libpio\.settings))
though there might be a better way to handle this?

@philipwjones
Copy link
Contributor

philipwjones commented Sep 23, 2020

On the E3SM side, we're using scorpio (our pio variant with pio2 interfaces that supports ADIOS for more performant I/O). It does not have a .settings file so that proposed fix wouldn't work.

But I think this points to an issue with the current approach in the Makefile - and I've hit similar problems with CMake and attempts to detect MPI installations. The failure to build the test code can happen for a number of reasons - most frequently due to a missing/bad PIO environment variable which it reports fine. But it can fail for a number of mis-configured compiler/loader flags too. That appears to be the case with some of the failures reported here where the problem is due to a misconfigured build target or changes to pio and its includes/libs. So it might help to actually not redirect build output to /dev/null so we get an actual error message from the test build for further diagnosis? Or figure out a way to trap the different potential error modes and return a more useful message.

@xylar
Copy link
Collaborator

xylar commented Sep 26, 2020

The following change worked for me with both scorpio and the latest PIO2 (2.5.2):

ifneq ($(wildcard $(PIO_LIB)/libpio\.*), )
	ifneq "$(wildcard $(PIO_LIB)/libpio\.*)" "$(PIO_LIB)/libpio.settings"
		LIBS += -lpio
	endif
endif

I'll put in a PR to develop this weekend.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

7 participants