My cluster has just upgraded to a new version of MPI, and I'm using an old
one. It seems that I'm having trouble compiling due to the compiler wrapper
file moving (full error here: http://pastebin.com/EmwRvCd9)
"Cannot open configuration file
/opt/apps/openmpi/1.4.4-intel/share/openmpi/mpif90-wrapp
m you
> standard PATH and then use module to switch them in and out as needed.
>
> Doug Reeder
> On May 16, 2014, at 3:39 PM, Ben Lash wrote:
>
> My cluster has just upgraded to a new version of MPI, and I'm using an
> old one. It seems that I'm having trouble comp
:
1) intel/2013.1.039 2) python3/3.2.1 3) pgi/11.7
4) openmpi/1.4.4-intel 5) netcdf/4.1.3
[bl10@login2 ~]$
On Fri, May 16, 2014 at 5:46 PM, Gus Correa wrote:
> On 05/16/2014 06:26 PM, Ben Lash wrote:
>
>> I'm not sure I have the ability to implement a differen
17:58, Douglas L Reeder a écrit :
> >>> Ben,
> >>>
> >>> You might want to use module (source forge) to manage paths to
> different mpi implementations. It is fairly easy to set up and very robust
> for this type of problem. You would remove contentious appli
21, 2014 at 1:34 PM, Douglas L Reeder wrote:
> Ben,
>
> The netcdf/4.1.3 module maybe loading the openmpi/1.4.4 module. Can you do
> module show the netcdf module file to to see if there is a module load
> openmpi command.
>
> Doug Reeder
>
> On May 21, 2014, at 12:23 PM,
>
> Just out of curiosity, besides netcdf/4.1.3, did you load openmpi/1.6.5?
> Somehow the openmpi/1.6.5 should have been marked
> to conflict with 1.4.4.
> Is it?
> Anyway, you may want to do a 'which mpiexec' to see which one is
> taking precedence in your envir
ilar that can be turned on
> in the CPPFLAGS, which in many models makes a more verbose log.
> This *may* tell you where it fails (source file, subroutine and line),
> and may help understand why it fails.
> If it dumps a core file, you can trace the failure point with
> a debugger.
