sandialabs / seacas Goto Github PK

SEACAS's versioning scheme set the SEACAS_VERSION string incorrectly. It is really composed of major and minor version. Compare Trilinos:

SET(Trilinos_VERSION 12.5)
SET(Trilinos_MAJOR_VERSION 12)
SET(Trilinos_MAJOR_MINOR_VERSION 120500)
SET(Trilinos_VERSION_STRING "12.5 (Dev)")

Besides, a YEAR.MONTH scheme seems to be in place. This is probably to immediately recognize if a version is outdated or not.

However, this approach has flaws. One obvious shortcoming is that you cannot make two releases shortly after one another. More importantly, though, SEACAS is missing out on the semantic meaning of major and minor versions. Typically, a major version change indicates an API change, a minor version indicates that functionality has been added in a backwards-compatible way.

Hi Greg,

When i try to install the SEACAS package , I get the error message as below.

I follow the instruction on https://github.com/gsjaardema/seacas#get-the-sources

any ideas?

Thanks .

iKnowledge

Peter Chen

e: [email protected]

May also fail with other types; only discovered with element variables.

Hi Greg,
I built the exodus library so I can export an exodus file from a special-purpose meshing code.
I have a small suggestion for the netcdf build instructions here:
https://github.com/gsjaardema/seacas#exodus

The netcdf instructions talk about setting C and LD FLAGS with respect to HDF5_ROOT, but I couldn’t find any mention of what HDF5_ROOT should be.
Eventually I figured out it should be the same as ACCESS.

Also, FYI, this might be helpful to some.
I had an old version of hdf5 install somewhere on my machine that netcdf was finding and using, but it wasn’t compatible because it didn’t define 'H5LT_FILE_IMAGE_DONT_COPY' and the like. The configure step would succeed without complaint but then I’d get the following compile error.

libtool: compile: gcc -DHAVE_CONFIG_H -I. -I.. -I../include -MT libnetcdf4_la-nc4file.lo -MD -MP -MF .deps/libnetcdf4_la-nc4file.Tpo -c nc4file.c -fno-common -DPIC -o .libs/libnetcdf4_la-nc4file.o
nc4file.c:2321:30: warning: implicit declaration of function
'H5LTopen_file_image' is invalid in C99 [-Wimplicit-function-declaration]
if((nc4_info->hdfid = H5LTopen_file_image(meminfo->memory,meminfo->size,
^
nc4file.c:2322:4: error: use of undeclared identifier
'H5LT_FILE_IMAGE_DONT_COPY'
H5LT_FILE_IMAGE_DONT_COPY|H5LT_FILE_IMAGE_DONT_RELEASE
^
nc4file.c:2322:30: error: use of undeclared identifier
'H5LT_FILE_IMAGE_DONT_RELEASE'
H5LT_FILE_IMAGE_DONT_COPY|H5LT_FILE_IMAGE_DONT_RELEASE
^
1 warning and 2 errors generated.
make[2]: *** [libnetcdf4_la-nc4file.lo] Error 1
make[1]: *** [all-recursive] Error 1
make: *** [all] Error 2

... samitch

Good afternoon Greg,

I was curious if ejoin block/set merging was serviced in SEACAS? I recall talking about this late last August.

I still have work arounds, but thought it wouldn’t hurt to ask.

Thanks,
Steve Gomez

Document that variables created via a command-line include are immutable.

https://prod.sandia.gov/sierra-trac/ticket/15760#comment:1

Perhaps @bartlettroscoe can help out here: I'm trying to enable all SEACAS packages, I tried

  -DSEACASProj_ENABLE_ALL_PACKAGES:BOOL=ON \
  -DSEACASProj_ENABLE_ALL_OPTIONAL_PACKAGES:BOOL=ON \
  -DSEACASProj_ENABLE_SECONDARY_TESTED_CODE:BOOL=ON \

With this, however, I'm still getting

Final set of non-enabled SE packages:  SEACASSVDI SEACASPLT SEACASBlot SEACASFastq 4

I'm not even sure if I need all of the parameters above.

When configuring with

cmake  \
  -DBUILD_SHARED_LIBS:BOOL=ON \
  -DSEACASProj_ENABLE_ALL_PACKAGES:BOOL=ON \
  -DTPL_ENABLE_MPI:BOOL=OFF \
  ../source-upstream/

not all libraries are built dynamically. Check out

[ 37%] Linking C static library libexodus.a
[ 55%] Linking C static library libchaco.a
[ 55%] Linking C shared library libsuplib_c.so
[ 57%] Linking Fortran shared library libsupes.so

hi,
My compiler is gcc4.7. I installed seacas software according to the installation manual step by step ,When I execute make&makeinstall command, there are the following errors:
../packages/seacas/libraries/aprepro_lib/apr_util.cc: In function ?. oid SEAMS::math_error(const SEAMS::Aprepro&,const char*)?.:178:9error:?.ath_errhandling?. was not declared in this scope
How can I solve it？Looking forward to reply. thanks.

Add reflect/mirror {x|y|z} option to ejoin.

Should work with offset -- need to specify order of operation -- mirror followed by offset.

Investigate how to specify for more than two input meshes.
Investigate how to handle results variables.

I'm trying to add a nodal variable to an exodus file that has pre-existing nodal variables with the exodus python wrapper.

It appears that the "set_node_variable_number" function can only succeed when no nodal variable files exist in the file.

The traceback follows:
File "/home/acochrane/goma/TPL_exp/seacas/lib/exodus.py", line 4956, in add_variables exo.set_node_variable_number(n_vars)
File "/home/acochrane/goma/TPL_exp/seacas/lib/exodus.py", line 905, in set_node_variable_number self.__ex_put_variable_param(ndType, number)
File "/home/acochrane/goma/TPL_exp/seacas/lib/exodus.py", line 4337, in __ex_put_variable_param raise Exception, ("ERROR: ex_put_variable_param had problems. This can only be called once per varType.")
Exception: ERROR: ex_put_variable_param had problems. This can only be called once per varType.

Intermediate solution is to:

1. create a new file with the resulting number of variables
2. copy the old variables in
3. copy the new variable in

The README at the head of Chaco here:

https://github.com/gsjaardema/seacas/tree/master/packages/seacas/libraries/chaco

only contains a broken link

The file

usr/bin/exodus.py

triggers two Debian warnings:

• script-with-language-extension
• executable-not-elf-or-script

The first states that for executables, it should not matter for the user in which language it is written. That's why you won't find any *.* files in /usr/bin of your usual Linux installation.
The second is related to that, and can be fixed by adding the appropriate shebang to the top of the file, i.e.,

#!/usr/bin/env python

I was directed here from https://sourceforge.net/projects/exodusii/, which says

As of 2016-02-08, this project may now be found at https://github.com/gsjaardema/seacas.git.

However, when I tried to build exodus as before:

cd packages/seacas/libraries/exodus
mkdir -p _build
cd _build
(
export CPPFLAGS="-I${CMAKE_DIR}/include -I${CURL_DIR}/include -I${HDF5_DIR}/include -I${MPI_DIR}/include -I${NETCDF4_DIR}/include -I${OPENSSL_DIR}/include -I${PATCHELF_DIR}/include -I${PYTHON_DIR}/include -I${TRILINOS_DIR}/include -I${ZLIB_DIR}/include"
export LDFLAGS="-L${CMAKE_DIR}/lib -Wl,-rpath=${CMAKE_DIR}/lib -L${CURL_DIR}/lib -Wl,-rpath=${CURL_DIR}/lib -L${HDF5_DIR}/lib -Wl,-rpath=${HDF5_DIR}/lib -L${MPI_DIR}/lib -Wl,-rpath=${MPI_DIR}/lib -L${NETCDF4_DIR}/lib -Wl,-rpath=${NETCDF4_DIR}/lib -L${OPENSSL_DIR}/lib -Wl,-rpath=${OPENSSL_DIR}/lib -L${PATCHELF_DIR}/lib -Wl,-rpath=${PATCHELF_DIR}/lib -L${PYTHON_DIR}/lib -Wl,-rpath=${PYTHON_DIR}/lib -L${TRILINOS_DIR}/lib -Wl,-rpath=${TRILINOS_DIR}/lib -L${ZLIB_DIR}/lib -Wl,-rpath=${ZLIB_DIR}/lib"
${CMAKE} -DCMAKE_INSTALL_PREFIX:PATH="${ARTIFACT}" \
  -DCMAKE_POSITION_INDEPENDENT_CODE:BOOL=ON \
  -DCMAKE_INSTALL_RPATH:STRING="${ARTIFACT}/lib" \
  -DCMAKE_INSTALL_RPATH_USE_LINK_PATH:BOOL=ON \
  -DCMAKE_BUILD_TYPE:STRING=Release \
  -DCMAKE_PREFIX_PATH="${CMAKE_DIR};${CURL_DIR};${HDF5_DIR};${MPI_DIR};${NETCDF4_DIR};${OPENSSL_DIR};${PATCHELF_DIR};${PYTHON_DIR};${TRILINOS_DIR};${ZLIB_DIR}" \
  -D BUILD_SHARED=ON -D NETCDF_SO_ROOT:PATH="${NETCDF4_DIR}/lib" -D PYTHON_INSTALL:PATH="${ARTIFACT}/lib/python2.7/site-packages" \
  ..
)
${CMAKE} --build . -- -j ${HASHDIST_CPU_COUNT}
make install

it fails to build now:

[exodus] -- The C compiler identification is GNU 5.3.1
[exodus] -- The CXX compiler identification is GNU 5.3.1
[exodus] -- Check for working C compiler: /usr/bin/cc
[exodus] -- Check for working C compiler: /usr/bin/cc -- works
[exodus] -- Detecting C compiler ABI info
[exodus] -- Detecting C compiler ABI info - done
[exodus] -- Detecting C compile features
[exodus] -- Detecting C compile features - done
[exodus] -- Check for working CXX compiler: /usr/bin/c++
[exodus] -- Check for working CXX compiler: /usr/bin/c++ -- works
[exodus] -- Detecting CXX compiler ABI info
[exodus] -- Detecting CXX compiler ABI info - done
[exodus] -- Detecting CXX compile features
[exodus] -- Detecting CXX compile features - done
[exodus] CMake Error at CMakeLists.txt:1 (INCLUDE):
[exodus]   include could not find load file:
[exodus] 
[exodus]     TribitsSubPackageMacros
[exodus] 
[exodus] 
[exodus] CMake Error at CMakeLists.txt:2 (INCLUDE):
[exodus]   include could not find load file:
[exodus] 
[exodus]     TribitsLibraryMacros
[exodus] 
[exodus] 
[exodus] CMake Error at CMakeLists.txt:3 (TRIBITS_SUBPACKAGE):
[exodus]   Unknown CMake command "TRIBITS_SUBPACKAGE".
[exodus] 
[exodus] 
[exodus] CMake Warning (dev) in CMakeLists.txt:
[exodus]   No cmake_minimum_required command is present.  A line of code such as
[exodus] 
[exodus]     cmake_minimum_required(VERSION 3.4)
[exodus] 
[exodus]   should be added at the top of the file.  The version specified may be lower
[exodus]   if you wish to support older CMake versions for this project.  For more
[exodus]   information run "cmake --help-policy CMP0000".
[exodus] This warning is for project developers.  Use -Wno-dev to suppress it.
[exodus] 
[exodus] -- Configuring incomplete, errors occurred!
[exodus] See also "/home/certik/.hashdist/tmp/exodus-c7scl5mgwd6o/packages/seacas/libraries/exodus/_build/CMakeFiles/CMakeOutput.log".

I tested the commit 2bceb5e. Note that the file http://downloads.sourceforge.net/project/exodusii/exodus-6.09.tar.gz used to work just fine with the above procedure, but it's gone now...

The cmake error is caused by the fact that this line:

https://github.com/gsjaardema/seacas/blob/9dc57a31536194216c36167714450781a8b95db8/packages/seacas/libraries/exodus/CMakeLists.txt#L1

assumes that the CMakeLists.txt is part of some larger project which includes the TribitsSubPackageMacros macro. This line in the README:

https://github.com/gsjaardema/seacas/blob/9dc57a31536194216c36167714450781a8b95db8/packages/seacas/libraries/exodus/README#L29

suggests that it is possible to use cmake to build exodus. Is that still possible? If exodus can't be build as a standalone library anymore, then I think that's a major problem.

/usr should probably be the default setting for HDF5_ROOT.

I see in CMakeLists.txt

cmake_minimum_required(VERSION 3.0)

Is this actually required? I just tested with 2.8.12 and it seems all fine.

Greg,

I am currently running gjoin in effort to remove the majority of my FEA blocks in order to perform a sub analysis, but I am currently receving a “Program received signal SIGSEGV: Segmentation fault – invalid memory reference” error and was hoping that you might be able to provide some insight. I have tried running this on my blad in as well as the cee-compute007 (with more memory). I have attached the python script used to create the gjoin command file in addition to the associated command file. I have given you the mesh on chama if necessary using the below commands.

give gdsjaar tsl_g2a_asm_qsdv_negy.g
take spgomez tsl_g2a_asm_qsdv_negy.g

Thanks,
Steve

Gregory,

I have a feature / implementation idea for the exo2mat and mat2exo functions. My idea revolves around how to implement variables what have their index in their name (e.g. blkXX, gvarXX, nvarXX, evarXX, ssfacXX etc)

If I want to loop through my variables I currently do one of two things:

clear
load('sample_output_matlab.mat');  %nnvars = 15

1. This method uses the eval function to create a temporary variable for me to operate on. Of course, while the eval function does the job, it is clunky to use in this manner and can’t be compiled (always interpreted). http://www.mathworks.com/help/matlab/matlab_prog/string-evaluation.html

%% Method 2
for ii = 1:nnvars
    varData = eval(['nvar' sprintf('%02d',ii) ';'])
end

1. What I prefer to do is to transfer all the pertinent variables to cell arrays.

%% Method 3
% Convert nvarXX into an indexable cell array
NVAR = cell(nnvars,1);
for ii = 1:nnvars
    NVAR{ii} = eval(['nvar' sprintf('%02d',ii) ';'])
    eval(['clear nvar' sprintf('%02d',ii)])
end
% Can loop through variables serially
for ii = 1:nnvars
    varData = NVAR{ii};
end
% Can loop through variables in parallel
parfor ii = 1:nnvars
    varData = NVAR{ii};
end

In the workspace this would look like this:

As opposed to this:

In addition to functionality, I like that it cleans up my workspace (Condenses hundreds of nvars, evars, gvars, ssfacs, ssnodes, sselems, blks etc into fewer variable icons)

Would it be possible to have exo2mat generate cell-arrays for the relevant variables? And could mat2exo convert .mat files with cell arrays? Maybe through a command line flag?

(I think it’s still good to list variables in the current manner, as I think it’s more accessible for “light-users” of Matlab who may not be accustomed to cell arrays.)

Best Regards,
G------ V-----

I can't find a LICENSE file in the main directory. Also, the README.md should state under which license SEACAS is published.

Add fortran wrappers for all ex_get_partial_* functions.

Verify that all public C API functions have a Fortran counterpart.

I see that SEACAS is bundling a bunch of TPLs. This is probably to make it easier for new users to get started with SEACAS.

However, version bundling has serious downsides:

• upstream fixes don't automatically make it to SEACAS,
• SEACAS installations will conflict with upstream installations,
• bundled software will get tweaked without getting the patches upstream, leading to an unupdatable mess.

I personally just bumped in number 2 with a Trilinos installation; Zoltan is conflicting here.
There are more elaborate texts on this.

Of course, we still want to make it easy for newcomers to get started with SEACAS. That's why I prepare a PPA, too.

There has to be the possibility to depend on system-installed libraries though, and I'd suggest to make it the default. Then, if anyone pulls

-DBUILD_BUNDLED_TPLS:BOOL=ON

he or she gets it all.

When the configure_file command generates the decomp script in the build directory it does not have an executable permission set. If this did, then panzer, Drekar and other apps could avoid having to install seacas separately during testing. I will submit a pull request with this change shortly.

It appears that nem_spread is configurable through a text file, but not through command line. This always creates a hassle for me since I use nem_spread from a script, and in there I have to open a file, write to it, call nem_spread, and delete the file.

It'd be a lot more convenient if it was fully configurable through command line.

(Besides, how do I tune it to spit out out files like test.e.2.0, not test.par.2.0?)

I'm dismayed to find the Exodus release tar files have been purged from sourceforge. Are these archived somewhere else? I'd be looking for the last one made, I suppose. The seacas package is way too big to be including as a distributed TPL when all that is wanted is exodus.

When building SEACAS with

cmake  \
  -D SEACAS_ENABLE_ALL_PACKAGES:BOOL=ON \
  -D SEACAS_ENABLE_TESTS:BOOL=ON \
  -D BUILD_SHARED_LIBS:BOOL=ON \
  -D TPL_ENABLE_CGNS:BOOL=OFF \
  -D TPL_ENABLE_Matio:BOOL=ON \
  -D TPL_ENABLE_METIS:BOOL=ON \
  -D TPL_ENABLE_ParMETIS:BOOL=ON \
  -D TPL_ENABLE_Netcdf:BOOL=ON \
  -D TPL_ENABLE_MPI:BOOL=OFF \
  -D TPL_ENABLE_Pamgen:BOOL=OFF \
  -D TPL_ENABLE_X11:BOOL=OFF \
  -D TPL_ENABLE_Zlib:BOOL=ON \
  ../source-nschloe/

I get a bunch of failing tests:

$ ctest
[...]
The following tests FAILED:
      5 - Zoltan_ch_bug_parmetis_serial (Failed)
     13 - Zoltan_ch_ewgt_parmetis_serial (Failed)
     15 - Zoltan_ch_grid20x19_parmetis_serial (Failed)
     17 - Zoltan_ch_hammond_parmetis_serial (Failed)
     23 - Zoltan_ch_nograph_parmetis_serial (Failed)
     25 - Zoltan_ch_onedbug_parmetis_serial (Failed)
     29 - Zoltan_ch_simple_parmetis_serial (Failed)
     33 - Zoltan_ch_vwgt_parmetis_serial (Failed)
     35 - Zoltan_ch_vwgt2_parmetis_serial (Failed)
     49 - Zoltan_problemGRAPH (OTHER_FAULT)

See https://launchpadlibrarian.net/223760348/buildlog_ubuntu-xenial-amd64.seacas_15.10~201510301340-xenial1_BUILDING.txt.gz for more details.

I'm getting build errors of the kind

In file included from /home/nschloe/software/seacas/source-upstream/packages/zoltan/src/tpls/parmetis_interface.h:53:0,
                 from /home/nschloe/software/seacas/source-upstream/packages/zoltan/src/tpls/parmetis_interface.c:52:
/home/nschloe/software/seacas/source-upstream/packages/zoltan/src/tpls/third_library_const.h:249:31: error: unknown type name ‘ZOLTAN_ID_PTR’

for a while now. One configuration to reproduce the error:

cmake  \
  -DBUILD_SHARED_LIBS:BOOL=ON \
  -DSEACASProj_ENABLE_ALL_PACKAGES:BOOL=ON \
  -DSEACASProj_ENABLE_ALL_OPTIONAL_PACKAGES:BOOL=ON \
  -DSEACASProj_ENABLE_SECONDARY_TESTED_CODE:BOOL=ON \
  -DSEACASProj_ENABLE_TESTS:BOOL=ON \
  -DSEACASProj_USE_GNUINSTALLDIRS:BOOL=ON \
  -DHDF5_ROOT:PATH=/usr \
  \
  -DTPL_ENABLE_CGNS:BOOL=ON \
  -DTPL_ENABLE_Matio:BOOL=ON \
  -DTPL_ENABLE_METIS:BOOL=ON \
  -DTPL_ENABLE_ParMETIS:BOOL=ON \
  -DTPL_ENABLE_Netcdf:BOOL=ON \
  -DTPL_ENABLE_MPI:BOOL=OFF \
  -DTPL_ENABLE_Pamgen:BOOL=OFF \
  -DTPL_ENABLE_X11:BOOL=OFF \
  -DTPL_ENABLE_Zlib:BOOL=ON \
  \
  ../source-upstream/

(Can probably be shortened.)

When checking the output of

make install

I see that MPI files are installed by SEACAS:

-rw-r--r-- root/root      8165 2015-10-31 10:37 ./usr/include/mpi.h
-rw-r--r-- root/root       882 2015-10-31 10:37 ./usr/include/mpi_config.h
-rw-r--r-- root/root      7855 2015-10-31 10:37 ./usr/include/mpi_implementation.h
-rw-r--r-- root/root     21197 2015-10-31 10:37 ./usr/include/mpi_profile.h
-rw-r--r-- root/root     20831 2015-10-31 10:37 ./usr/include/mpi_prototypes.h

This should be fixed. If those aren't actually MPI files, they should at least be prefixed with seacas_ or seacas/.

While working on trilinos/Trilinos#158, I noticed that SEACAS optionally uses ParMETIS but is not properly declaring its dependence on the TriBITS TPL ParMETIS. You can see this by looking at:

$ cd Trilinos/packages/seacas/
$  find . -name CMakeLists.txt -exec grep -nHi parmetis {} \;
./libraries/ioss/src/CMakeLists.txt:16:IF (${PROJECT_NAME}_ENABLE_ParMETIS)
./libraries/ioss/src/CMakeLists.txt:17:  SET(PARMETIS_LIB "parmetis")
./libraries/ioss/src/CMakeLists.txt:19:  ADD_DEFINITIONS(-DNO_PARMETIS_SUPPORT)
./libraries/ioss/src/CMakeLists.txt:41:  ${PARMETIS_LIB}
./libraries/ioss/src/cgns/CMakeLists.txt:12:IF (${PROJECT_NAME}_ENABLE_ParMETIS)
./libraries/ioss/src/cgns/CMakeLists.txt:13:  SET(PARMETIS_LIB "parmetis")
./libraries/ioss/src/cgns/CMakeLists.txt:15:  ADD_DEFINITIONS(-DNO_PARMETIS_SUPPORT)
./libraries/ioss/src/exo_par/CMakeLists.txt:11:IF (${PROJECT_NAME}_ENABLE_ParMETIS)
./libraries/ioss/src/exo_par/CMakeLists.txt:12:  SET(PARMETIS_LIB "parmetis")
./libraries/ioss/src/exo_par/CMakeLists.txt:14:  ADD_DEFINITIONS(-DNO_PARMETIS_SUPPORT)
./libraries/ioss/src/exo_par/CMakeLists.txt:31:  DEPLIBS Ioss Ioex ${PARMETIS_LIB}

There are a few problems with this approach:

1. The SEACASIoss CMakeLists.txt files have to manually pull in the ParMETIS libs. If you list the TPL dependence in Dependencies.cmake, then those libs will be included automatically when the TPL is enabled.
2. SEACASIoss assumes the library name is "parametis" but that may not always be the case on every system. Letting the TriBITS TPL system handle this allows the user to point to whatever libraries that need to that supply ParMETIS.
3. A user can't disable support for just ParMETIS in SEACAS if there is some problem on some platform. For example, other Trilinos packages also optionally use ParMETIS like Zoltan, Zoltan2, Amesos, Amesos2, ML and ShyLU. Let's say that there is some problem building SEACAS with the certain version of ParMETIS installed on some platform but the other packages build with this version of ParMETIS just fine. In this case, the user may not need to use ParMETIS with SEACAS but they do need ParMETIS with a subset of these other packages. By having SEACAS properly declare an optional dependency on ParMETIS, the user can configure with -DSEACASIoss_ENABLE_ParMETIS=OFF and then they can still build and do what they need. With the current setup of SEACASIoss, they can't do that.

To fix this:

1. List ParaMETIS in the file seacas/libraries/ioss/cmake/Dependencies.cmake in the list LIB_OPTIONAL_LIBS
2. Remove the CMakeList.txt code that directly adds the library "parametis"

For more documentation on optional TPLs, see:

• https://tribits.org/doc/TribitsDevelopersGuide.html#how-to-add-a-new-tribits-tpl-dependency
• https://tribits.org/doc/TribitsDevelopersGuide.html#package-name-enable-optional-dep-tpl-name
• https://tribits.org/doc/TribitsDevelopersGuide.html#support-for-optional-se-package-tpl-can-be-explicitly-disabled

cd TPL/cgns
git clone https://github.com/CGNS/CGNS.git

should be followed by

cd CGNS

I think SEACAS depends on curl, but does not automatically add -lcurl during compilation. For instance, I was getting the following errors

Linking Fortran executable gen3d
../../libraries/exodus/libexodus.so.12.9: undefined reference to `curl_easy_perform'
../../libraries/exodus/libexodus.so.12.9: undefined reference to `curl_easy_getinfo'
../../libraries/exodus/libexodus.so.12.9: undefined reference to `curl_easy_init'
../../libraries/exodus/libexodus.so.12.9: undefined reference to `curl_easy_strerror'
../../libraries/exodus/libexodus.so.12.9: undefined reference to `curl_version_info'
../../libraries/exodus/libexodus.so.12.9: undefined reference to `curl_easy_cleanup'
../../libraries/exodus/libexodus.so.12.9: undefined reference to `curl_easy_setopt'
collect2: error: ld returned 1 exit status

I have a proper /usr/lib64/libcurl.so but it was not picked up because of the missing -lcurl for executable linking.

The current workaround for me is to add the following to my CMake configuration:

-D CMAKE_EXE_LINKER_FLAGS="-lcurl"

When

-D TPL_ENABLE_Netcdf:BOOL=ON \

and a serial installation of NetCDF is found and MPI is turned on, the build fails with

[ 77%] Building C object src/libraries/exodus/cbind/CMakeFiles/exodus.dir/src/ex_create_par.c.o
cd /home/nschloe/software/seacas/build/src/libraries/exodus/cbind && /usr/bin/mpicc  -DNOT_NETCDF4 -Dexodus_EXPORTS -pedantic -Wall -Wno-long-long -std=c99 -fPIC -I/home/nschloe/software/seacas/build -I/home/nschloe/software/seacas/source-upstream/src/libraries/exodus/cbind/include -I/home/nschloe/software/seacas/build/src/libraries/exodus/cbind/include    -o CMakeFiles/exodus.dir/src/ex_create_par.c.o   -c /home/nschloe/software/seacas/source-upstream/src/libraries/exodus/cbind/src/ex_create_par.c
/home/nschloe/software/seacas/source-upstream/src/libraries/exodus/cbind/src/ex_create_par.c:130:24: fatal error: netcdf_par.h: No such file or directory
 #include "netcdf_par.h"
                        ^
compilation terminated.

This should probably be intercepted at configure stage.

Greg,
Revisiting our gen3d discussion from November…

As we work to set up our Trinity open science runs, it turns out that our workflow would benefit by having mirroring as an option for our extrusions of wedge elements (or alternatively the option to extrude in the +z direction). I did try mirroring and it mangles the side sets on the extruded mesh. This is not urgent since we do have a workaround, but I wanted to document the behavior since you will probably want to provide mirroring for this use case at some point.

Matt

There have been no requests for this until today. It wouldn’t take too long to implement with side 1 being nodes 1 to 2 and side 2 being nodes 2 to 1. I think that the Ioss already does this since you could already store this in exodus, you just couldn’t get it to give you the nodes or node count…

I will add as an enhancement request on the SEACAS github site. You could have Joel Miller add a trac enhancement if you want to track it internally.

..Greg

Greg,
I don't think the exodus manual has a definition for a sideset on a beam. Is that supported? Is it in the works?
-Garth

@gdsjaar,

FYI:

When using the macro TRIBITS_PACKAGE_DEFINE_DEPENDENCIES() in a Dependencies.cmake file, you don't need to set dependency vars anymore. They all get set in the macro arguments and those that are empty are set to "" automatically. For example, see TribitsExampleProject/with_subpackages/cmake/Dependencies.cmake which shows:

TRIBITS_PACKAGE_DEFINE_DEPENDENCIES(
  SUBPACKAGES_DIRS_CLASSIFICATIONS_OPTREQS
    A   a   PT  REQUIRED
    B   b   ST  OPTIONAL
    C   c   ST  OPTIONAL
  )

Therefore, in the file seacas/cmake/Dependencies.cmake, you don't need to set the vars:

SET(LIB_REQUIRED_DEP_PACKAGES)
SET(LIB_OPTIONAL_DEP_PACKAGES)
SET(TEST_REQUIRED_DEP_PACKAGES)
SET(TEST_OPTIONAL_DEP_PACKAGES)
SET(LIB_REQUIRED_DEP_TPLS)
SET(LIB_OPTIONAL_DEP_TPLS MPI)
SET(TEST_REQUIRED_DEP_TPLS)
SET(TEST_OPTIONAL_DEP_TPLS)

They get set to empty "" by the macro TRIBITS_PACKAGE_DEFINE_DEPENDENCIES() automatically. This just removes clutter and avoids mistakes (that can be hidden by clutter).

Hope this is helpful.

Greg,

Okay, good to know.. I would need this capability at the start of Q3 (this
year) in support of my VVUQ project. I may have alternative paths in
Percept, however, let me check on that... I think that Percept might promote
a mesh from P1 to P2. We certainly support arbitrary promotion in Nalu now
(P1->P12-ish) however, that is internal to the code and for my VV study I
want a pure quadratic hex mesh.

Best,

Stefan

In the cmake-config file, starting on line 101, there is an open string literal without a closing string literal:

if [ "HAVE_DATA_WAREHOUSE" == "ON" ]
then
    DW_SYMBOLS="-DSEACASIoss_ENABLE_DataWarehouse=${HAVE_DATAWAREHOUSE} \
                -DTPL_ENABLE_DataWarehouse:BOOL=${HAVE_DATAWAREHOUSE}   \
                -DDataWarehouse_LIBRARY_DIRS:PATH=${DataWarehouse_PATH}/lib     \
                -DDataWarehouse_INCLUDE_DIRS:PATH=${DataWarehouse_PATH}/include \
fi

Note that DW_SYMBOLS=" has no closing ". Bash throws an error and quits compilation.

I'm now getting

Getting information for all enabled TPLs ...

Processing enabled TPL: Netcdf (enabled explicitly, disable with -DTPL_ENABLE_Netcdf=OFF)
-- NetCDF include file /usr/include/netcdf.h will be searched for define values
CMake Warning at cmake/modules/FindNetCDF.cmake:147 (message):
  The NetCDF found in does not have the correct NC_MAX_DIMS, NC_MAX_VARS and
  NC_MAX_VAR_DIMS

  It may not be compatible with other TPL libraries such MOAB and ExodusII

and I have no idea what this wants to say. I'm running on a default NetCDF 4.1.3. Perhaps too old?

Now that SEACAS is on GitHub, we can think about how to make it easy to snapshot this repo into Trilinos. @bartlettroscoe has something in place for TriBits and I think this is working pretty smooth. The general storyline would be the following:

• Create a base TriBITS project called SEACASProj or something, and then have the base directory organized like:

  seacas/
    ProjectName.cmake   # SET(PROJECT_NAME SEACASProj)
    PackagesList.cmake  # List two packages, Zoltan, and SEACAS
    TPLsList.camke      # Same as now
    packages/
      seacas/           # Main source for the SEACAS pacakge
      zoltan/           # Snapshot of Zoltan/ dir from Trilinos
    TPL/                # Only externally built TPLs
      cgns/
      …
      serial_mpi/        
    …
  

  The rest of the directories would be the same.

• With this layout, the directory seacas/packages/seacas/ would be directly snapshotted into Trilinos like:

  $ export SEACAS_PROJ=???
  $ cd Trilinos/package/seacas/
  $ ../../cmake/tribits/python_utils/shapshot-dir.py --orig-dir=$SEACUS_PROJ/packages/seacus/

• Then run the checkin-test.py script to push.

Bonus Level

If we want to allow for local changes to SEACAS in Trilinos, we should snapshot to a branch and them merge like:

$ cd Trilinos/package/seacas/
$ git checkout --track origin/seacas-github-snapshot
$ ./snapshot_seacas.sh
$ git push   # to origin/seacas-github-snapshot
$ git checkout master
$ git merge --no-ff seacas

That will allow for local urgent changes to seacas/ in the Trilinos ‘master’ branch to not get overwritten by the snapshot. The process for moving changes from Trilinos/packages/secacas/ to seacas/packages/seacas/ would require using git format-patch and git am and it would be more fragile because there is no root commit to resolve merge conflicts.

This is about the exactly same workflow used for TriBITS. It is the same in that a subdir from a separate repo is snapshotted into a directory under Trilinos. That part is exactly the same.

We can also test changes before the snapshot into Trilinos with:

    -DSEACAS_SOURCE_DIR=$SEACAS_PROJ/packages/seacas

TPL_ENABLE_CGNS might not be turning on the right defines

I get the following error when trying to build without CGNS (and without MATIO)

In file included from /home/wortiz/projects/goma/libraries/seacas/packages/seacas/libraries/ioss/src/Ioss_DatabaseIO.C:42:
/home/wortiz/projects/goma/libraries/seacas/packages/seacas/libraries/ioss/src/Ioss_StructuredBlock.h:46:10: fatal error: 
      'cgnstypes.h' file not found
#include <cgnstypes.h>
         ^~~~~~~~~~~~~
1 error generated.
packages/seacas/libraries/ioss/src/CMakeFiles/Ioss.dir/build.make:158: recipe for target 'packages/seacas/libraries/ioss/src/CMakeFiles/Ioss.dir/Ioss_DatabaseIO.C.o' failed
make[2]: *** [packages/seacas/libraries/ioss/src/CMakeFiles/Ioss.dir/Ioss_DatabaseIO.C.o] Error 1
CMakeFiles/Makefile2:4520: recipe for target 'packages/seacas/libraries/ioss/src/CMakeFiles/Ioss.dir/all' failed

But my cmake was configured with CGNS off:

$ cmake -LA -N .. |grep TPL_ENABLE_CGNS
TPL_ENABLE_CGNS:BOOL=OFF

Changes to cmake-config:

$ git diff
diff --git a/cmake-config b/cmake-config
index a811b6c..36aff94 100755
--- a/cmake-config
+++ b/cmake-config
@@ -31,8 +31,8 @@ INSTALL_PATH=${ACCESS}
 ### subdirectories of the specified paths.
 ### For example, netcdf.h should be in ${NETCDF_PATH}/include
 HAVE_NETCDF=ON
-HAVE_MATIO=ON
-HAVE_CGNS=ON
+HAVE_MATIO=OFF
+HAVE_CGNS=OFF
 
 NETCDF_PATH=${ACCESS}
 MATIO_PATH=${ACCESS}

Thrown error:

../cmake-config
CMake Error: -D must be followed with VAR=VALUE.
CMake Error: Problem processing arguments. Aborting.

../cmake-config: line 133: -D: command not found

Relevant line in cmake-config:

131:  -D TPL_ENABLE_MPI:BOOL=${MPI} \
132:  -D TPL_ENABLE_Pamgen:BOOL=OFF \
133:  -D 
134:  -D TPL_ENABLE_Pthread:BOOL=${THREADSAFE_IO_LIBS} \

See #26

Noticed that the exodus_for/CMakeLists.txt doesn't add the exodus/include search path despite it being required by the exodus_for/src/exo_jack.c source file to include exodusII.h.

(note that I haven't actually verified I get this error in this repository, rather it was something I came across while compiling the version petsc packages up and went here to see how it had been addressed and as far as I can tell it hasn't)

The folder

src/doc-source/exodus/old/

contains apparently obsolete files, and also some binaries. Yikes! Those files will be in Git history for all time, so if they are actually obsolete, they could as well be git rmed.

Right now, SEACAS's documentation is almost than half as heavy as the actual packages,

$ du -sh *
[...]
28M doc
[...]
58M packages
[...]

This is mostly due to the presence of some scanned files, e.g., FASTQ.pdf at 11MB. Several files exceed 1MB. It'd be probably be worthwhile considering moving those files to another place (e.g., github pages) and linking it from the README.

Looks like the links are case sensitive

e.g. instead of algebra linking to : http://gsjaardema.github.io/seacas/Algebra.pdf

It should link to: http://gsjaardema.github.io/seacas/algebra.pdf

There are a few others that have this issue as well.

In the set of all enabled and disables packages and TPLs, I don't see HDF5:

Enabling all parent packages that have at least one subpackage enabled ...


Final set of enabled packages:  Zoltan IOSS Supes Aprepro_lib Chaco SVDI 6

Final set of enabled SE packages:  Zoltan IOSSIoss IOSSIogn IOSSIohb IOSSIotr IOSSIonit IOSSIoMain IOSSIoUtest IOSS Supes Aprepro_lib Chaco SVDI 13

Final set of non-enabled packages:  Exodus Exodus_for Nemesis Suplib Mapvarlib PLT Algebra Aprepro Blot Conex Conjoin Ejoin Epu Ex1ex2v2 Ex2ex1v2 Exo2mat Exo_format Exodiff Exomatlab Exotec2 Exotxt Fastq Gen3D Genshell Gjoin Grepos Grope Mapvar Mapvar-kd Mat2exo Nemslice Nemspread Numbers Txtexo 34

Final set of non-enabled SE packages:  Exodus Exodus_for Nemesis IOSSIoex IOSSIofx IOSSIopx IOSSIoexo_fac IOSSIocgns IOSSIopg Suplib Mapvarlib PLT Algebra Aprepro Blot Conex Conjoin Ejoin Epu Ex1ex2v2 Ex2ex1v2 Exo2mat Exo_format Exodiff Exomatlab Exotec2 Exotxt Fastq Gen3D Genshell Gjoin Grepos Grope Mapvar Mapvar-kd Mat2exo Nemslice Nemspread Numbers Txtexo 40

Final set of enabled TPLs:  X11 1

Final set of non-enabled TPLs:  Zlib Pnetcdf Netcdf CGNS METIS ParMETIS Pamgen Matio 8

Setting up export dependencies for all enabled SE packages ...

Intentional?

Below is a simple main function to test the ex_create_int api function from the exodus libarary, howver I got the error , and it is really strange i "_ex_create_int" undefined symbols, I am suspecting it is this underscore in front of ex_create_int is giving me problem , I also try the other function ex_open , ex_close , and all these giving me the similar message .

#include
#include "exodusII.h"
using namespace std;

int main() {

float version;
int CPU_word_size = sizeof(float);
int IO_word_size = 8;
int exoid= ex_create("./test.exo",
EX_CLOBBER,
&CPU_word_size,
&IO_word_size);
}

Error Message :
g++ main.o -o output -fopenmp
Undefined symbols for architecture x86_64:
"_ex_create_int", referenced from:
_main in main.o
ld: symbol(s) not found for architecture x86_64
collect2: error: ld returned 1 exit status
make: *** [output] Error 1