Install difficulties

[aolofsson]

I tried to follow the build procedure verbatim, but clearly I am missing something.

https://xyce.sandia.gov/documentation/BuildingGuide.html

See install file and config log attached. Has this been built on Ubuntu 18.04? Exact procedure below.

#!/bin/bash

###########################################################################
# References:
#
# https://xyce.sandia.gov/documentation/BuildingGuide.html
#
###########################################################################

#Dependancies
sudo apt-get install gfortran bison flex libfl-dev libfftw3-dev libsuitesparse-dev libsuitesparse-doc libblas-dev liblapack-dev libtool libopenmpi-dev openmpi-bin libtrilinos-teuchos-dev

###########################################################################
#Install Trilinos from source
wget https://github.com/trilinos/Trilinos/archive/trilinos-release-12-12-1.tar.gz 
tar zxvf trilinos-release-12-12-1.tar.gz
mkdir -p XyceLibs/Serial
SRCDIR=$PWD/Trilinos-trilinos-release-12-12-1
ARCHDIR=$PWD/XyceLibs/Serial
FLAGS="-O3 -fPIC"
cmake \
-G "Unix Makefiles" \
-DCMAKE_C_COMPILER=gcc \
-DCMAKE_CXX_COMPILER=g++ \
-DCMAKE_Fortran_COMPILER=gfortran \
-DCMAKE_CXX_FLAGS="$FLAGS" \
-DCMAKE_C_FLAGS="$FLAGS" \
-DCMAKE_Fortran_FLAGS="$FLAGS" \
-DCMAKE_INSTALL_PREFIX=$ARCHDIR \
-DCMAKE_MAKE_PROGRAM="make" \
-DTrilinos_ENABLE_NOX=ON \
-DNOX_ENABLE_LOCA=ON \
-DTrilinos_ENABLE_EpetraExt=ON \
-DEpetraExt_BUILD_BTF=ON \
-DEpetraExt_BUILD_EXPERIMENTAL=ON \
-DEpetraExt_BUILD_GRAPH_REORDERINGS=ON \
-DTrilinos_ENABLE_TrilinosCouplings=ON \
-DTrilinos_ENABLE_Ifpack=ON \
-DTrilinos_ENABLE_Isorropia=ON \
-DTrilinos_ENABLE_AztecOO=ON \
-DTrilinos_ENABLE_Belos=ON \
-DTrilinos_ENABLE_Teuchos=ON \
-DTeuchos_ENABLE_COMPLEX=ON \
-DTrilinos_ENABLE_Amesos=ON \
-DAmesos_ENABLE_KLU=ON \
-DTrilinos_ENABLE_Sacado=ON \
-DTrilinos_ENABLE_Kokkos=OFF \
-DTrilinos_ENABLE_ALL_OPTIONAL_PACKAGES=OFF \
-DTrilinos_ENABLE_CXX11=ON \
-DTPL_ENABLE_AMD=ON \
-DAMD_LIBRARY_DIRS="/usr/lib" \
-DTPL_AMD_INCLUDE_DIRS="/usr/include/suitesparse" \
-DTPL_ENABLE_BLAS=ON \
-DTPL_ENABLE_LAPACK=ON \
$SRCDIR

make

sudo make install

##############################################################################

#Clone Xyce
git clone git@github.com:Xyce/Xyce.git

#Build Xyce
cd Xyce
./bootstrap
cd ../
./configure CXXFLAGS="-O3 -std=c++11" ARCHDIR="/home/aolofsson/work/darpa/POSH/sandia-spice/Serial" CPPFLAGS="-I/usr/include/suitesparse"

config.log

[tvrusso]

Please review the building guide's instructions about ARCHDIR.

You are installing your Trilinos libraries into $HOME/XyceLibs/Serial, but are giving a completely different ARCHDIR to Xyce's configure script. They should be the same.

From the building guide:

We recommend installing Trilinos, built especially according to the directions in this guide, into a separate directory. In the earlier section on building Trilinos, we instructed you to use a variable called "ARCHDIR" in your CMake invocation for Trilinos. Xyce's configure script also has a variable called "ARCHDIR" that can be used not only to find these libraries and headers, but also some extra files that help determine interdependencies between Trilinos packages and link in all required Trilinos libraries. Simply use the same install directory you gave to the Trilinos CMake script (ARCHDIR) as the value of Xyce's configure ARCHDIR:

/path/to/Xyce/configure ARCHDIR=$HOME/XyceLibs/Serial [other configure options]

Since you are providing inconsistent ARCHDIRs to the two build processes, Xyce's configure is being told to look for Trilinos in some other place than where you actually installed it.

Further, the building guide discourages you from attempting to use any version of Trilinos provided in your system's package management system, because no package managers ever build Trilinos with the same options that Xyce needs. From the "Install prerequisite packages" section:

Note that at this time no system provides packages for versions of Trilinos that are compatible with Xyce, so it will always need to be built from source. While some systems do provide packages for Trilinos in package management systems, these versions are either too old to be used or are not configured to have all the essential package options required by Xyce, and we do not recommend using them even if you happen to find one for your system.

You have "libtrilinos-teuchos-dev" in your apt-get command. You should remove this package, which may cause conflicts with the version you built from source .

[tvrusso]

A few more points: you are installing Trilinos to $HOME/XyceLibs/Serial, but are using "sudo make install" to do so. It is unnecessary to use sudo to install into a directory that you own, and doing so will simply make the files in your own home directory be owned by root instead of you.

[tvrusso]

One last batch of comments. It looks like you want Xyce itself to be installed in /home/aolofsson/work/darpa/POSH/sandia-spice/Serial, which you tried to do by specifying that directory as ARCHDIR. That's probably because we used that variable name to set the "CMAKE_INSTALL_PREFIX" in the instructions for building Trilinos. We did it that way to try to emphasize that Trilinos was getting installed into ARCHDIR, and we are later telling Xyce to look for it there by using a variable of the same name.

ARCHDIR is used to tell configure where to look for libraries specific to your architecture (not necessarily just trilinos --- you could install other system-specific things there if you had to build them from source for some reason).

If you want configure to set you up so that "make install" will put Xyce somewhere other than its default /usr/local (which we definitely recommend you do), you use the "--prefix" option to configure. From the building guide:

Specifying alternate installation directory

By default, configure will set up the Xyce build process so that "make install" installs Xyce components into subdirectories /usr/local: the executable will go in /usr/local/bin, associated libraries into /usr/local/lib, and header files into /usr/local/include. This behavior can be changed by adding the "--prefix" option to configure:

path/to/Xyce/configure
--prefix=/opt/Xyce
...

The example above will cause "make install" to install into /opt/Xyce/bin, /opt/Xyce/lib, and /opt/Xyce/include.

If you do not have root privileges on your system, this procedure can allow you to install Xyce into a directory that you own instead. Otherwise, use "sudo" with "make install" to install Xyce into system directories.

The Xyce Team STRONGLY recommends that you always specify a "--prefix" for Xyce builds, and not use the default "/usr/local." Installing both serial and parallel versions of Xyce directly into /usr/local will cause the two versions to overwrite some components and leave one or the other unusable.

So what you really want in your configure line is:
./configure CXXFLAGS="-O3 -std=c++11" ARCHDIR=$HOME/XyceLibs/Serial --prefix="/home/aolofsson/work/darpa/POSH/sandia-spice/Serial" CPPFLAGS="-I/usr/include/suitesparse"

We also strongly discourage building the code inside its source directory, because that pollutes the directory with build artifacts, and can make it difficult to build multiple variants of Xyce (e.g. both serial and parallel builds) because droppings from a previous build might interfere with the next one. Instead of running "./configure" inside the source tree you should create an empty build directory somewhere and build there. This isolates the build artifacts from the source tree and keeps the source tree pristine. Please do the following instead of "./configure":

cd Xyce
git clean -Xf     # this will get rid of any droppings that your previous configure attempt created
./bootstrap
cd ../
mkdir build_Xyce_Serial
cd build_Xyce_Serial
../Xyce/configure CXXFLAGS="-O3 -std=c++11" ARCHDIR="/home/aolofsson/work/darpa/POSH/sandia-spice/Serial" CPPFLAGS="-I/usr/include/suitesparse"
make
make install

Your source tree will remain clean and your build directory will contain only build artifacts. Should you want to build Xyce for parallel runs as well, you would create a second build directory and issue your parallel configure line there.

This technique is also useful when the source tree resides on a remotely mounted filesystem shared by multiple computers of different architectures --- the same source tree can be used to build for all the different systems without each system stepping on the other.

The building guide's instructions all presuppose that you are following this guidance. Per the building guide, again:

Build Directories

It is important to note that our recommendations for building Trilinos and Xyce make use of "out-of-source" builds. This means that the executables and/or libraries are built in a directory completely separate from the directory containing the source code. This is accomplished by creating an empty directory anywhere in the file system of your computer (the "build directory"), and using appropriate arguments in "configure" scripts to tell the build system where to find the source code (the "source directory").

Doing builds in directories separate from the source code keeps the original source tree pristine, and allows you to build many different versions (specifically, both serial and parallel versions) without changing the source tree. It also permits sharing a single source tree over a networked filesystem, and building the code for multiple operating systems without copying the source to every machine. This process is described in detail in the generic "INSTALL" file included at the top level of the Xyce source tree; this file is part of the GNU Automake system, and is not specific to Xyce.

This assumption of out-of-source builds is also evident in the Linux-specific example configure line we provide:

Linux

If all packages have been installed as recommended, configuring on Linux is fairly simple. This is because the package manager installs all of its packages in /usr/lib and /usr/include, and these are searched by configure and the compilers with no extra options required.

The example configure invocation below should be appropriate for any distribution of Linux, though it has only been tested specifically on Red Hat, Ubuntu, and Linux Mint variants. Minor modifications may be necessary on other distros.

/path/to/Xyce/configure \
CXXFLAGS="-O3 -std=c++11" \
ARCHDIR="$HOME/XyceLibs/Serial" \
CPPFLAGS="-I/usr/include/suitesparse"

[aolofsson]

Yes, I succeeded in the end. My apologies for turning an RTFM problem on my part into an issue. I do question why one would leave it up to stupid users (like me) to mess up the paths, if there is only one correct way of doing it. Attaching the script I used.

###########################################################################
# References:
#
# https://xyce.sandia.gov/documentation/BuildingGuide.html
# https://github.com/Xyce/Xyce
#
###########################################################################

###########################################################################
#Install Dependancies
###########################################################################

sudo apt-get install gfortran bison flex libfl-dev libtool
sudo apt-get install libfftw3-dev libsuitesparse-dev libblas-dev liblapack-dev
sudo apt-get install libopenmpi-dev openmpi-bin

###########################################################################
#Install Trilinos from source
###########################################################################

wget https://github.com/trilinos/Trilinos/archive/trilinos-release-12-12-1.tar.gz 
tar zxvf trilinos-release-12-12-1.tar.gz

SRCDIR=$PWD/Trilinos-trilinos-release-12-12-1
LIBDIR=/opt/xyce/xyce_lib
INSTALLDIR=/opt/xyce/xyce_serial
FLAGS="-O3 -fPIC"

cmake \
-G "Unix Makefiles" \
-DCMAKE_C_COMPILER=gcc \
-DCMAKE_CXX_COMPILER=g++ \
-DCMAKE_Fortran_COMPILER=gfortran \
-DCMAKE_CXX_FLAGS="$FLAGS" \
-DCMAKE_C_FLAGS="$FLAGS" \
-DCMAKE_Fortran_FLAGS="$FLAGS" \
-DCMAKE_INSTALL_PREFIX=$LIBDIR \
-DCMAKE_MAKE_PROGRAM="make" \
-DTrilinos_ENABLE_NOX=ON \
-DNOX_ENABLE_LOCA=ON \
-DTrilinos_ENABLE_EpetraExt=ON \
-DEpetraExt_BUILD_BTF=ON \
-DEpetraExt_BUILD_EXPERIMENTAL=ON \
-DEpetraExt_BUILD_GRAPH_REORDERINGS=ON \
-DTrilinos_ENABLE_TrilinosCouplings=ON \
-DTrilinos_ENABLE_Ifpack=ON \
-DTrilinos_ENABLE_Isorropia=ON \
-DTrilinos_ENABLE_AztecOO=ON \
-DTrilinos_ENABLE_Belos=ON \
-DTrilinos_ENABLE_Teuchos=ON \
-DTeuchos_ENABLE_COMPLEX=ON \
-DTrilinos_ENABLE_Amesos=ON \
-DAmesos_ENABLE_KLU=ON \
-DTrilinos_ENABLE_Sacado=ON \
-DTrilinos_ENABLE_Kokkos=OFF \
-DTrilinos_ENABLE_ALL_OPTIONAL_PACKAGES=OFF \
-DTrilinos_ENABLE_CXX11=ON \
-DTPL_ENABLE_AMD=ON \
-DAMD_LIBRARY_DIRS="/usr/lib" \
-DTPL_AMD_INCLUDE_DIRS="/usr/include/suitesparse" \
-DTPL_ENABLE_BLAS=ON \
-DTPL_ENABLE_LAPACK=ON \
$SRCDIR

make

sudo mkdir -p $LIBDIR
sudo make install

###########################################################################
#Install Xyce from Source
###########################################################################

#Clone Xyce
git clone git@github.com:Xyce/Xyce.git

#Build Xyce
cd Xyce
./bootstrap
./configure CXXFLAGS="-O3 -std=c++11" ARCHDIR=$LIBDIR --prefix=$INSTALLDIR CPPFLAGS="-I/usr/include/suitesparse"
make
sudo mkdir -p $INSTALLDIR
sudo make install

#Test installation
$INSTALLDIR/bin/Xyce

[tvrusso]

The reason is that there is NOT "one correct way to do it."

The configure script is extraordinarily flexible and allows for all sorts of ridiculous permutations of system configuration. We provide guidance on a recommended way to do it that keeps everything consistent, and if that guidance is followed then things are easy. If the user knows better and wants to do something else, the capability is there.

A big problem here is that there are so many ways to compile Trilinos, and their default build is not suited to use with Xyce. It is difficult for autoconf to pick up how Trilinos is compiled (although we try pretty hard to detect it and give a minimum of dials that have to be set just right). But if one doesn't tell Xyce's configure where to look for Trilinos's libraries and headers, then it has no way of finding them. Once it finds them, it does as best it can to detect what components of the Trilinos install are needed and whether they will work.

[Cahui1]

Excuse me, what should I do when I install xyce and try to run it

[Karlsefni2012]

It looks like the Xyce binary isn't in your path.

[Karlsefni2012]

Also it is a bit strange to be running Xyce directly inside of your "bin" directory. I'd check the permissions on that directory, and recommend running it a directory that you own.

[tvrusso]

It is likely that "." is not in your PATH, as that is often considered a security problem.

You should add "~/XyceInstall/Parallel/bin" to your PATH, then run your netlist in some other directory. You should not usually put netlists and output in the bin directory.

Please do not add questions like this to a years-old concluded discussion, but rather create a new discussion (you also opened an issue for this same problem, which we similarly ask people not to do --- issues are for reporting bugs in Xyce, discussions are for asking questions).

Your new issue was converted to a discussion #63 and further commentary should be continued there.

[mguthaus]

I'm following similar instructions where I put the ARCHDIR in /software/XyceLibs/Parallel. I've compiled Trilinos with all of the parallel enables from the suggestions in Xyce Trilinos install instructions (including Amesos_ENABLE_KLU), but when I run Xyce configure I get:
../Xyce/configure CXXFLAGS="-O3 -std=c++1" ARCHDIR="/software/XyceLibs/Parallel" --prefix=/software/xyce --prefix="-I/usr/include/suitesparse"
...
configure: error: Sorry, KLU headers not found.

They are very clearly in /software/XyceLibs/Parallel/include. (I'm building Xyce in a separate directory as suggested...)

[Karlsefni2012]

The "prefix" should only be specified once on the configure line. It looks like you are setting it twice, and the second one should instead be CPPFLAGS="-I/usr/include/suitesparse" . "prefix" is just supposed to be the directory where Xyce will be installed.

[tvrusso]

The message "Sorry, KLU headers not found" will show up if for some reason configure cannot compile a file that includes "Amesos_Klu.h". The primary reason for that would be the file not existing, but there could be other reasons for the compile to fail --- and the message on the console would be unchanged.

Please look in the file "config.log" to see exactly what error message the compiler emitted when it tried to compile that test program. It will be the most telling explanation of what's wrong and how to fix it.

If you can't find that bit of config.log, attach your config.log file here and I can take a look.

[tvrusso]

The "prefix" should only be specified once on the configure line. It looks like you are setting it twice, and the second one should instead be CPPFLAGS="-I/usr/include/suitesparse" . "prefix" is just supposed to be the directory where Xyce will be installed.

Well spotted, I'd missed that. By not putting -I/usr/include/suitesparse into CPPFLAGS, it could be that the test compile of the file that includes "Amesos_Klu.h" is failing to find some suitesparse header it needs. I am not entirely sure which suitesparse header that would be, but it's possible. Even if that's not the source of the "KLU headers not found" problem, it will cause other problems and should be fixed before digging further.

The config.log file would be the real clue as to what's going on, though.

[mguthaus]

Oops, that was a cut & paste error -- I'm not redefining the prefix.

…

On Thu, Mar 4, 2021 at 10:42 AM Tom Russo ***@***.***> wrote: The "prefix" should only be specified once on the configure line. It looks like you are setting it twice, and the second one should instead be CPPFLAGS="-I/usr/include/suitesparse" . "prefix" is just supposed to be the directory where Xyce will be installed. Well spotted, I'd missed that. By not putting -I/usr/include/suitesparse into CPPFLAGS, it could be that the test compile of the file that includes "Amesos_Klu.h" is failing to find some suitesparse header it needs. I am not entirely sure *which* suitesparse header that would be, but it's possible. Even if that's not the source of the "KLU headers not found" problem, it will cause other problems and should be fixed before digging further. The config.log file would be the real clue as to what's going on, though. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#4 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AC67SL4ESRMXCGQO4B77SSTTB7ICDANCNFSM4YTYMXCQ> .

-- Matthew Guthaus Associate Dean of Graduate Studies Professor, Computer Science & Engineering Baskin School of Engineering University of California Santa Cruz https://www.soe.ucsc.edu/people/mrg

[tvrusso]

Then the real key to what's going on will be found in your config.log file, down where configure compiles a small test program that includes Amesos_Klu.h. That compile is failing, and probably not because Amesos_Klu.h doesn't exist. Find that reason, and you'll be on your way.

If you can't find that, attach your config.log file and I can probably spot it quickly.

[tvrusso]

AH! Unless this is another cut-and-paste error, you've got "-std=c++1" in your CXXFLAGS rather than "-std=c++11".

On the current master branch, configure figures out for itself how to get C++11 support, so you could leave this out entirely (the documentation in the building guide is only updated at release time, so it hasn't yet been changed to reflect this improvement in configure). But specifying "-std=c++1" could probably mess things up.

[mguthaus]

(I tried attaching it but it didn't go through...) It seems that it isn't finding mpi.h actually. I have openmpi and the dev libraries installed so I'll explicitly add some configure paths to those in the configure arguments.

…

On Thu, Mar 4, 2021 at 10:49 AM Tom Russo ***@***.***> wrote: Then the real key to what's going on will be found in your config.log file, down where configure compiles a small test program that includes Amesos_Klu.h. That compile is failing, and probably not because Amesos_Klu.h doesn't exist. Find that reason, and you'll be on your way. If you can't find that, attach your config.log file and I can probably spot it quickly. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#4 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AC67SLYMGTQ7FLYKSILIE63TB7I5LANCNFSM4YTYMXCQ> .

-- Matthew Guthaus Associate Dean of Graduate Studies Professor, Computer Science & Engineering Baskin School of Engineering University of California Santa Cruz https://www.soe.ucsc.edu/people/mrg

[tvrusso]

That should not be necessary if you're correctly specifying CC=mpicc and CXX=mpicxx to match what was used to build Trilinos. It doesn't look like you're doing that, though.

The mpi compiler wrappers pass the correct paths needed to find MPI headers and libraries.

[tvrusso]

See for example the suggested configure invocation for building parallel Xyce on Linux at https://xyce.sandia.gov/documentation/BuildingGuide.html#parallelLinuxXyce. There we have:

/path/to/Xyce/configure \
CXXFLAGS="-O3 -std=c++11" \
ARCHDIR="$HOME/XyceLibs/Parallel" \
CPPFLAGS="-I/usr/include/suitesparse" \
--enable-mpi \
CXX=mpicxx \
CC=mpicc \
F77=mpif77 \
--prefix=$HOME/XyceInstall/Parallel

Here we hit all the bases: path to ARCHDIR, prefix into which Xyce should be installed, enabling MPI, and passing the correct compiler wrappers as CC and CXX.

Your cut/pasted configure invocation was missing "--enable-mpi" and the compiler wrappers.

[mguthaus]

That was another cut & paste error. If I add an include path explicitly to where mpi.h is and I add "--enable-mpi" to the configure line it seem to make it further...

…

On Thu, Mar 4, 2021 at 10:52 AM Tom Russo ***@***.***> wrote: AH! Unless this is another cut-and-paste error, you've got "--std=c++1" in your CXXFLAGS rather than "--std=c++11". On the current master branch, configure figures out for itself how to get C++11 support, so you could leave this out entirely (the documentation in the building guide is only updated at release time, so it hasn't yet been changed to reflect this improvement in configure). But specifying "--std=c++1" could probably mess things up. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#4 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AC67SL6AKHD7TC274E6MDBLTB7JG5ANCNFSM4YTYMXCQ> .

-- Matthew Guthaus Associate Dean of Graduate Studies Professor, Computer Science & Engineering Baskin School of Engineering University of California Santa Cruz https://www.soe.ucsc.edu/people/mrg

[tvrusso]

Yes. That would have helped. You need to specify the compiler wrappers as well. Please review https://xyce.sandia.gov/documentation/BuildingGuide.html#parallelBuilds, where we've tried to document the correct procedure, complete with a few system-specific examples.

[tvrusso]

You should NOT need to specify a path to where mpi.h is, and should not. This is a sign that you are not using the correct compiler wrappers as CC and CXX.

If you look again at https://xyce.sandia.gov/documentation/BuildingGuide.html#parallelBuilds you'll see that all of our guidance tells you to do that.

If you use the compiler wrappers that MPI provides, you'll get those paths automatically.

[mguthaus]

It works without doing that and specifying the enable mpi and wrappers. It wasn't clear that I needed to do that at first.

…

On Thu, Mar 4, 2021 at 11:01 AM Tom Russo ***@***.***> wrote: You should NOT need to specify a path to where mpi.h is, and should not. This is a sign that you are not using the correct compiler wrappers as CC and CXX. If you look again at https://xyce.sandia.gov/documentation/BuildingGuide.html#parallelBuilds you'll see that all of our guidance tells you to do that. If you use the compiler wrappers that MPI provides, you'll get those paths automatically. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#4 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AC67SL25YLMYZXONPWX7TETTB7KJBANCNFSM4YTYMXCQ> .

-- Matthew Guthaus Associate Dean of Graduate Studies Professor, Computer Science & Engineering Baskin School of Engineering University of California Santa Cruz https://www.soe.ucsc.edu/people/mrg

[mwette]

I did compile a while ago on 18.04 (IRRC). I just compiled on Ubuntu 22.04. I have also been trying to compile dakota so some of my chnages are due to desire to be able to build dakota against trilinos as well, and with shared libraries. So this setup may or may not be useful, as I am experimenting a bit.

• trilinos
  triilinos commit: a6d3274e2f75876e7d682e34f92b12dded96f014

Here is my config command:

cmake \
	-D CMAKE_INSTALL_PREFIX=/opt/sandia \
	-D BUILD_SHARED_LIBS=ON \
	-D PYTHON_EXECUTABLE:FILEPATH=/usr/bin/python3.9 \
	-D Trilinos_ENABLE_COMPLEX=ON \
	-D CMAKE_CXX_FLAGS="-O1 -std=gnu++20" \
	-D TPL_AMD_INCLUDE_DIRS="/usr/include/suitesparse" \
	-D Trilinos_ENABLE_Fortran=ON \
	-D Trilinos_ENABLE_COMPLEX=ON \
	-D Trilinos_ENABLE_ALL_PACKAGES=ON \
	-D TPL_ENABLE_Netcdf=OFF \
	-D Amesos_ENABLE_KLU=ON \
	-D MPI_BASE_DIR=/usr/lib/x86_64-linux-gnu/openmpi \
	-C ../../xyce/Xyce/cmake/trilinos/trilinos-config-MPI.cmake \
	../Trilinos

I did make this change to get it to compile with -std=gnu++20:

index b50b82eb017..29c56239249 100644
--- a/cmake/tribits/core/config_tests/FiniteValue.cmake
+++ b/cmake/tribits/core/config_tests/FiniteValue.cmake
@@ -58,7 +58,7 @@ INCLUDE(CheckCXXSourceCompiles)
 
 SET(SOURCE_GLOBAL_ISNAN
   "
-#include <cmath>
+#include <math.h>
 int main()
 {
   double x = 1.0;
@@ -105,7 +105,7 @@ ENDIF()
 
 SET(SOURCE_GLOBAL_ISINF
   "
-#include <cmath>
+#include <math.h>
 int main()
 {
   double x = 1.0;

*xyce

xyce commit: 1b7c261

config command:

cmake \
	-D CMAKE_INSTALL_PREFIX=/opt/sandia \
	-D BUILD_SHARED_LIBS=ON \
	-D Trilinos_ROOT=/opt/sandia \
	-D CMAKE_CXX_FLAGS="-O2 -std=gnu++20" \
	-D Xyce_ROL=OFF \
	-D Xyce_SHYLU=OFF \
	../Xyce

[EDIT: After reversing this, I found it is not needed. So, one of the changes I made on the path to completion resolved this issue.]

And I did this hack to get around an error about finding a matching signature for the call to DeviceCountMapSum().

--- a/src/CircuitPKG/N_CIR_Xyce.C
+++ b/src/CircuitPKG/N_CIR_Xyce.C
@@ -1075,10 +1075,13 @@ Simulator::RunStatus Simulator::initializeLate()
 
     IO::gatherGlobalDeviceCount(comm_, global_device_count_map, deviceManager_->getDeviceCountMap());
 
+#if 0
     auditJSON_ << Util::nameValuePair("StartTime", timeDate) << Util::JSON::sep
                << Util::nameValuePair("DeviceCount", global_device_count_map) << Util::JSON::sep
                << Util::nameValuePair("DeviceTotalCount", std::accumulate(global_device_count_map.begin(), global_device_count_map.end(), 0, IO::DeviceCountMapSum()));
 
+// no match: IO::DeviceCountMapSum()
+#endif
     IO::printDeviceCount(Xyce::lout(), global_device_count_map);
   }

[TBird2001]

@mwette, I'm glad this approach worked for you. We are trying to design the CMake to be robust against different Trilinos builds, so it is nice to see it working against a full build (I've tried that only once, myself, since it takes so long to compile). You also seem to have discovered the support for ROL and ShyLU aren't fully there, yet. I don't think anyone on the team has tried compiling against the C++20 standard.

I see in your Trilinos configuration that you specified MPI_BASE_DIR, but not TPL_ENABLE_MPI=ON. I'm not sure if the former turns on the latter automatically, or not, so you might need to verify the MPI is working as expected.

Thanks for the feedback. We are continuing to make the CMake system more robust, such that it should be the recommended process for the Xyce 7.4 release (in the November time frame).

[mwette]

Thanks TBird,

I rebuilt with the TPL_ENABLE_MPI=ON, and my previous patches backed out (so no patching now).
I do get the following error with Xyce. Any ideas? Cmake commands appear below.

EDIT: Never mind the MPI errors. It comes with errors in the netlist. WIth a valid netlist the Xyce runs to completion without MPI errors.

mwette$ Xyce xycedemo.cir

---

***** Welcome to the Xyce(TM) Parallel Electronic Simulator

---

***** This is version Xyce DEVELOPMENT-202106100537-g-1b7c2610-opensource
***** Date: Thu Jun 10 06:19:26 PDT 2021

***** Executing netlist xycedemo.cir

***** Reading and parsing netlist...
Netlist error in file xycedemo.cir at or near line 46
Unrecognized line
Simulation aborted due to error. There are 0 MSG_FATAL errors and 1 MSG_ERROR
errors
*** Xyce Abort ***
Simulation aborted due to error. There are 0 MSG_FATAL errors and 1 MSG_ERROR
errors

*** Xyce Abort ***

MPI_ABORT was invoked on rank 0 in communicator MPI_COMM_WORLD
with errorcode 1.

NOTE: invoking MPI_ABORT causes Open MPI to kill all MPI processes.
You may or may not see output from other processes, depending on
exactly when Open MPI kills them.

Trilinos cmake:

cmake
-D CMAKE_INSTALL_PREFIX=/opt/sandia
-D BUILD_SHARED_LIBS=ON
-D PYTHON_EXECUTABLE:FILEPATH=/usr/bin/python3.9
-D Trilinos_ENABLE_COMPLEX=ON
-D CMAKE_CXX_FLAGS="-O1 -std=gnu++20"
-D TPL_AMD_INCLUDE_DIRS="/usr/include/suitesparse"
-D Trilinos_ENABLE_Fortran=ON
-D Trilinos_ENABLE_COMPLEX=ON
-D Trilinos_ENABLE_ALL_PACKAGES=ON
-D TPL_ENABLE_Netcdf=OFF
-D Amesos_ENABLE_KLU=ON
-D TPL_ENABLE_MPI=ON
-D MPI_BASE_DIR=/usr/lib/x86_64-linux-gnu/openmpi
-C ../../xyce/Xyce/cmake/trilinos/trilinos-config-MPI.cmake
../Trilinos

Xyce cmake:

cmake
-D CMAKE_INSTALL_PREFIX=/opt/sandia
-D BUILD_SHARED_LIBS=ON
-D Trilinos_ROOT=/opt/sandia
-D CMAKE_CXX_FLAGS="-O2 -std=gnu++20"
-D Xyce_ROL=OFF
-D Xyce_SHYLU=OFF
../Xyce