Trilinos issueshttps://gitlab.osti.gov/jmwille/Trilinos/-/issues2019-03-14T20:53:27Zhttps://gitlab.osti.gov/jmwille/Trilinos/-/issues/4593PyTrilinos: Implement new infrastructure for nested sub-packages2019-03-14T20:53:27ZJames WillenbringPyTrilinos: Implement new infrastructure for nested sub-packages*Created by: wfspotz*
@trilinos/pytrilinos
## Expectations
All packages that have nested sub-packages should use the same infrastructure, and we need to avoid swig-generated base classes that include the `__init__` "module", becaus...*Created by: wfspotz*
@trilinos/pytrilinos
## Expectations
All packages that have nested sub-packages should use the same infrastructure, and we need to avoid swig-generated base classes that include the `__init__` "module", because this is not valid python syntax. Also, there are import issues that are different for Python 2 and Python 3, and the resulting solution should work for both.
## Current Behavior
Import issues keep cropping up, and some "solutions" create base classes with `__init__` in the module path.
## Possible Solution
* Use the relatively new `moduleimport` option for the `%module` SWIG directive to better control importing required modules.
* Change `__init__.py` modules from swig-generated, which includes a compiled extension, to pure python. Use `__init__.py.in` files to generate these files in
`packages/PyTrilinos/src/PyTrilinos`
* Change `Package.__init__.i` to `Package.i` and have it generate a python file `Package/Base.py` which is imported by the `__init__.py` file from the previous bullet. Use `globals().update(Base.__dict__)` to create references from everything in `Base` to the `__init__.py` file. Certain special variables, such as `__file__` will need to be preserved.
https://gitlab.osti.gov/jmwille/Trilinos/-/issues/3783PyTrilinos: How can I get the MPI include directory in a robust way?2018-10-31T18:44:06ZJames WillenbringPyTrilinos: How can I get the MPI include directory in a robust way?*Created by: wfspotz*
@trilinos/pytrilinos @trilinos/framework
## Expectations
In PyTrilinos, I have a python script that generates a SWIG interface file. That SWIG interface file needs to know where the `mpi.h` header file is, so ...*Created by: wfspotz*
@trilinos/pytrilinos @trilinos/framework
## Expectations
In PyTrilinos, I have a python script that generates a SWIG interface file. That SWIG interface file needs to know where the `mpi.h` header file is, so I can parse it and extract `MPI_VERSION`. I developed some logic to find it that worked for me, but it is not robust enough to work for all users. How can I obtain the MPI include path for finding `mpi.h` in a robust way?
## Current Behavior
In #3618 the user specifies his MPI configuration with
-D TPL_ENABLE_MPI:BOOL=ON
-D MPI_EXEC:FILEPATH=/opt/apps/xalt/0.6/bin/ibrun
but my script specifies the path to `mpi.h` incorrectly.
## Motivation and Context
Here is what I do. I start with a file `get_teuchos_rcp.py.in` that will get copied to the build directory with `cmake` variable substituted in. It has the following function defined to correctly interpret `cmake` boolean variables:
def cmake_bool(value):
if value.upper() in ("", "0", "FALSE", "N", "NO", "OFF"):
return False
return True
I then define python variable `WITH_MPI` (among many others) using
WITH_MPI = cmake_bool("${TPL_ENABLE_MPI}")
I then use this logic to define python variable `MPI_BASE_DIR`:
MPI_BASE_DIR = "${MPI_BASE_DIR}"
if WITH_MPI:
if MPI_BASE_DIR == "":
MPI_BIN_DIR = os.path.split("${MPI_CXX_COMPILER}")[0]
MPI_BASE_DIR = os.path.split(MPI_BIN_DIR)[0]
All this leads to supporting the following function:
def get_mpi_version():
header = os.path.join(MPI_BASE_DIR, "include", "mpi.h")
version = ""
for line in open(header, 'r').readlines():
if "MPI_VERSION" in line:
version = line.split()[2]
break
return version
But the assumption that `mpi.h` lives in `MPI_BASE_DIR/include` is wrong, because in my user's case, the actual path does not have an `include` suffix.
## Definition of Done
When the user in #3618 can build PyTrilinos at his installation, which is TACC.
## Possible Solution
Does the `cmake` logic that looks for MPI have logic that extracts the location of the `mpi.h` file? If not, could it be added?
## Related Issues
* Blocks #3618
https://gitlab.osti.gov/jmwille/Trilinos/-/issues/3618Is NOX buildable with python?2019-02-28T16:53:05ZJames WillenbringIs NOX buildable with python?*Created by: VictorEijkhout*
```
/admin/rpms/BUILD/trilinos-git/packages/PyTrilinos/src/NOX.__init__.i:130: Error: Unable to find 'NOX_Version.H'
packages/PyTrilinos/src/CMakeFiles/PyTrilinos_NOX___init__.dir/build.make:64: recipe for...*Created by: VictorEijkhout*
```
/admin/rpms/BUILD/trilinos-git/packages/PyTrilinos/src/NOX.__init__.i:130: Error: Unable to find 'NOX_Version.H'
packages/PyTrilinos/src/CMakeFiles/PyTrilinos_NOX___init__.dir/build.make:64: recipe for target 'packages/PyTrilinos/src/NOX.__init__PYTHON_wrap.cpp' failed
make[2]: *** [packages/PyTrilinos/src/NOX.__init__PYTHON_wrap.cpp] Error 1
[trilinos.log.gz](https://github.com/trilinos/Trilinos/files/2474856/trilinos.log.gz)
```https://gitlab.osti.gov/jmwille/Trilinos/-/issues/3430Build fails: Swig source step of building PyTrilinos fails with execvp: /bin/...2018-09-22T17:41:49ZJames WillenbringBuild fails: Swig source step of building PyTrilinos fails with execvp: /bin/sh: Argument list too long*Created by: casparvl*
@trilinos/pytrilinos
<!---
Assignees: If you know anyone who should likely tackle this issue, select them
from the Assignees drop-down on the right.
-->
<!---
Lables: Choose any applicable package nam...*Created by: casparvl*
@trilinos/pytrilinos
<!---
Assignees: If you know anyone who should likely tackle this issue, select them
from the Assignees drop-down on the right.
-->
<!---
Lables: Choose any applicable package names from the Labels drop-down on the
right. Additionally, choose a label to indicate the type of issue, for
instance, bug, build, documentation, enhancement, etc.
-->
<!---
Tell us what you think should happen, how you think things should work, what
you would like to see in the documentation, etc.
-->
## Current Behavior
<!---
Tell us how the current behavior fails to meet your expectations in some way.
-->
I am trying to build Trilinos 12.10.1 with python support. I ran into this issue (https://github.com/trilinos/Trilinos/issues/2434) where the build fails with an error 'execvp: /bin/sh: Argument list too long'. I fixed that by setting the suggested
```
CMAKE_CXX_USE_RESPONSE_FILE_FOR_OBJECTS=ON
CMAKE_CXX_USE_RESPONSE_FILE_FOR_INCLUDES=ON
CMAKE_CXX_USE_RESPONSE_FILE_FOR_LIBRARIES=ON
```
Which works well for the compilation part. However, the 'Swig source' step triggers the same error message, and clearly, doesn't respect these CMake flags.
`[ 94%] Swig source /scratch/shared/jenkins/test/build/Trilinos/12.10.1/foss-2017b-Python-2.7.14/trilinos-12.10.1-Source/packages/PyTrilinos/src/LOCA.Epetra.Interface.i
cd /scratch/shared/jenkins/test/build/Trilinos/12.10.1/foss-2017b-Python-2.7.14/trilinos-12.10.1-Source/BUILD/packages/PyTrilinos/src && /hpc/eb/RedHatEnterpriseServer7/SWIG/3.0.12-foss-2017b-Python-2.7.14/bin/swig -python -I/scratch/sha
red/jenkins/test/build/Trilinos/12.10.1/foss-2017b-Python-2.7.14/trilinos-12.10.1-Source/BUILD/packages/PyTrilinos/doc/Doxygen -noproxydel -outdir PyTrilinos/LOCA/Epetra -c++ -I/scratch/shared/jenkins/test/build/Trilinos/12.10.1/foss-201
7b-Python-2.7.14/trilinos-12.10.1-Source/BUILD -I/scratch/shared/jenkins/test/build/Trilinos/12.10.1/foss-2017b-Python-2.7.14/trilinos-12.10.1-Source/BUILD/packages/PyTrilinos/src`
[[[cut out a few hundred lines here]]]
`-I/scratch/shared/jenkins/test/build/Trilinos/12.10.1/foss-2017b-Python-2.7.14/trilinos-12.10.1-Source/BUILD
/packages/teuchos/remainder/src -I/scratch/shared/jenkins/test/build/Trilinos/12.10.1/foss-2017b-Python-2.7.14/trilinos-12.10.1-Source/packages/teuchos/numerics/src -o /scratch/shared/jenkins/test/build/Trilinos/12.10.1/foss-2017b-Python
-2.7.14/trilinos-12.10.1-Source/BUILD/packages/PyTrilinos/src/LOCA.Epetra.InterfacePYTHON_wrap.cpp /scratch/shared/jenkins/test/build/Trilinos/12.10.1/foss-2017b-Python-2.7.14/trilinos-12.10.1-Source/packages/PyTrilinos/src/LOCA.Epetra.I
nterface.i
make[2]: execvp: /bin/sh: Argument list too long
make[2]: *** [packages/PyTrilinos/src/LOCA.Epetra.InterfacePYTHON_wrap.cpp] Error 127
make[2]: Leaving directory `/scratch/shared/jenkins/test/build/Trilinos/12.10.1/foss-2017b-Python-2.7.14/trilinos-12.10.1-Source/BUILD'
make[1]: *** [packages/PyTrilinos/src/CMakeFiles/PyTrilinos_LOCA_Epetra_Interface.dir/all] Error 2
make[1]: *** Waiting for unfinished jobs....
make[2]: Leaving directory `/scratch/shared/jenkins/test/build/Trilinos/12.10.1/foss-2017b-Python-2.7.14/trilinos-12.10.1-Source/BUILD'`
## Possible Solution
<!---
Not obligatory, but suggest a fix for the bug or documentation, or suggest
ideas on how to implement the addition or change.
-->
Other then shortening the prefix on my end (which is tricky because I use EasyBuild as a build system, which produces somewhat long prefixes), is there anything that could be done on your end to fix this issue?
I can imagine even a shorter prefix is just a temporary relief, as future versions may trigger even _more_ includes. Thus, I think a more permanent solution for these excessively long command lines may be needed on your end anyway.
## Steps to Reproduce
<!---
Provide a link to a live example, or an unambiguous set of steps to reproduce
this issue. Include code to reproduce, if relevant.
1. Do this.
1. Do that.
1. Shake fist angrily at computer.
-->
To reproduce: pick a long enough prefix (and possibly build enough of Trilinos' components to get a long link line).
## Related Issues
<!---
If applicable, let us know how this bug is related to any other open issues:
-->
* Follows up on (somewhat) related issue https://github.com/trilinos/Trilinos/issues/2434
https://gitlab.osti.gov/jmwille/Trilinos/-/issues/3456PyTrilinos: Conflicting types in Teuchos_BLAS_wrapper.hpp2018-10-25T16:48:26ZJames WillenbringPyTrilinos: Conflicting types in Teuchos_BLAS_wrapper.hpp*Created by: wfspotz*
@trilinos/pytrilinos
@trilinos/teuchos
@trilinos/kokkos-kernels
## Expectations
I expect to build PyTrilinos without compilation errors
## Current Behavior
I have a wrapper file that `#include`s the he...*Created by: wfspotz*
@trilinos/pytrilinos
@trilinos/teuchos
@trilinos/kokkos-kernels
## Expectations
I expect to build PyTrilinos without compilation errors
## Current Behavior
I have a wrapper file that `#include`s the header `MLAPI_MultiVector.h` which gives the compilation error
/Development/Trilinos/packages/teuchos/numerics/src/Teuchos_BLAS_wrappers.hpp:173:13: error: conflicting types for 'daxpy_'
void PREFIX DAXPY_F77(const int* n, const double* alpha, const double x[], const int* incx, double y[], const int* incy);
^
/Development/Trilinos/packages/teuchos/numerics/src/Teuchos_BLAS_wrappers.hpp:78:21: note: expanded from macro 'DAXPY_F77'
#define DAXPY_F77 F77_BLAS_MANGLE(daxpy,DAXPY)
^
/Development/Trilinos/MPI/packages/teuchos/core/src/Teuchos_config.h:10:37: note: expanded from macro 'F77_BLAS_MANGLE'
#define F77_BLAS_MANGLE(name,NAME) name ## _
^
<scratch space>:23:1: note: expanded from here
daxpy_
^
/Development/Trilinos/packages/kokkos-kernels/src/impl/tpls/KokkosBlas1_axpby_tpl_spec_decl.hpp:49:17: note: previous declaration is here
extern "C" void daxpy_( const int* N, const double* alpha,
## Definition of Done
I can get the PyTrilinos package to build and all of the PyTrilinos tests to pass.
## Possible Solution
I'm not sure why this conflicting type declaration is occurring, but it is clearly related to macro expansion. Based on `git blame` of `Teuchos_BLAS_wrapper.h` I'm hoping either @jwillenbring or @hkthorn might have some idea what the problem could be. PyTrilinos can present some unique configuration issues.
## Steps to Reproduce
If it gets to this, I can help someone set up their environment to build PyTrilinos.
https://gitlab.osti.gov/jmwille/Trilinos/-/issues/2490PyTrilinos: Syntax error during compile2018-04-02T14:50:29ZJames WillenbringPyTrilinos: Syntax error during compile*Created by: emprice*
<!---
Provide a general summary of the issue in the Title above. If this issue
pertains to a particular package in Trilinos, it's worthwhile to start the
title with "PackageName: ".
-->
<!---
Note that ...*Created by: emprice*
<!---
Provide a general summary of the issue in the Title above. If this issue
pertains to a particular package in Trilinos, it's worthwhile to start the
title with "PackageName: ".
-->
<!---
Note that anything between these delimiters is a comment that will not appear
in the issue description once created. Click on the Preview tab to see what
everything will look like when you submit.
-->
<!---
Feel free to delete anything from this template that is not applicable to the
issue you are submitting.
-->
<!---
Replace <teamName> below with the appropriate Trilinos package/team name.
-->
<!---
Assignees: If you know anyone who should likely tackle this issue, select them
from the Assignees drop-down on the right.
-->
<!---
Lables: Choose any applicable package names from the Labels drop-down on the
right. Additionally, choose a label to indicate the type of issue, for
instance, bug, build, documentation, enhancement, etc.
-->
## Current Behavior
I configured Trilinos as follows:
```
PATH=/home/eprice/software/swig/bin:/home/eprice/software/gcc/bin:/home/eprice/software/binutils/bin:$PATH CC=/home/eprice/software/gcc/bin/gcc CXX=/home/eprice/software/gcc/bin/g++ HDF5_ROOT=/home/eprice/software/hdf5 /home/eprice/software/cmake/bin/cmake -DTPL_ENABLE_MPI=ON -DMPI_BASE_DIR=/home/eprice/software/mpich -DTrilinos_ENABLE_ALL_PACKAGES=ON -DTPL_ENABLE_Matio=OFF -DCMAKE_INSTALL_PREFIX=/home/eprice/software/trilinos -DBUILD_SHARED_LIBS=ON -DPYTHON_EXECUTABLE=/home/eprice/virtpy2/bin/python -DBLAS_LIBRARY_DIRS=/home/eprice/software/lapack/lib -DLAPACK_LIBRARY_DIRS=/home/eprice/software/lapack/lib -DBoost_INCLUDE_DIRS=/home/eprice/software/boost/include -DNetCDF_INCLUDE_DIRS=/home/eprice/software/netcdf/include -DNetCDF_LIBRARIES=/home/eprice/software/netcdf/lib/libnetcdf.so -DNetCDF_NEEDS_HDF5=ON -DNetCDF_PARALLEL=OFF -DBoostLib_LIBRARY_DIRS=/home/eprice/software/boost/lib ..
```
I get the following unexpected error during `make`:
```
[ 97%] Swig source /home/eprice/src/Trilinos-trilinos-release-12-12-1/packages/PyTrilinos/src/Domi.i
/home/eprice/src/Trilinos-trilinos-release-12-12-1/build/packages/PyTrilinos/doc/Doxygen/Tpetra_dox.i:14798: Error: Syntax error in input(1).
make[2]: *** [packages/PyTrilinos/src/DomiPYTHON_wrap.cpp] Error 1
make[1]: *** [packages/PyTrilinos/src/CMakeFiles/PyTrilinos_Domi.dir/all] Error 2
make: *** [all] Error 2
```
## Motivation and Context
I am compiling Trilinos as part of a larger software package, FEniCS. I can't move forward until the issue is resolved.
## Your Environment
<!---
Include relevant details about your environment such that we can replicate this
issue.
-->
I downloaded Trilinos directly from the Releases page: Trilinos-trilinos-release-12-12-1
Operating system: CentOS 6.9 x86_64
Compiler versions: gcc 6.3.0, using MPICH 3.2.1
## Additional Information
<!---
Anything else that might be helpful for us to know in addressing this issue:
* Configure log file:
* Build log file:
* Test log file:
* When was the last time everything worked (date/time; SHA1s; etc.)?
* What did you do that made the bug rear its ugly head?
* Have you tried turning it off and on again?
-->
I don't have root privileges on this machine (which is why my configure is so complicated -- I have local installs of a lot of my software). So any debugging/reconfiguring needs to be done in such a way that only my local installations are affected.https://gitlab.osti.gov/jmwille/Trilinos/-/issues/2327PyTrilinos: memory leak with repeated creation of CrsMatrix and solver.Iterate2018-03-05T21:55:51ZJames WillenbringPyTrilinos: memory leak with repeated creation of CrsMatrix and solver.Iterate*Created by: guyer*
Repeated creation of CrsMatrixen and AztecOO solvers causes memory to steadily leak
## Motivation and Context
We may be using PyTrilinos inappropriately, but [FiPy](https://github.com/usnistgov/fipy) creates a ...*Created by: guyer*
Repeated creation of CrsMatrixen and AztecOO solvers causes memory to steadily leak
## Motivation and Context
We may be using PyTrilinos inappropriately, but [FiPy](https://github.com/usnistgov/fipy) creates a new CrsMatrix and AztecOO solver at each iteration. Because of this leak, we have no choice but to regularly checkpoint and kill the job.
## Steps to Reproduce
Running [this modified version of exAztecOO.py](https://gist.github.com/guyer/f4ea5a0443d7bb25c18348661b4634d3) with
```
mprof run python exAztecOO.py
```
produces this plot
![leak](https://user-images.githubusercontent.com/1830725/36928860-a22ab122-1e57-11e8-8ea7-890b89f5c32e.png)
## Your Environment
- **Relevant configure flags or configure script:** Trilinos 12.10.1 installed from [this conda feedstock](https://github.com/guyer/trilinos-feedstock)
- **Operating system and version:** Mac OS X 10.12.6 and Debian GNU/Linux 8 (jessie)
## Additional Information
Based on [earlier discussions on the FiPy mailing list](https://www.mail-archive.com/search?l=fipy%40nist.gov&q=subject:%22Memory+Leaks+with+Trilinos%22&o=newest) the leak may have been introduced after version 11.10.2https://gitlab.osti.gov/jmwille/Trilinos/-/issues/2056Matrix Assembly Efficiency in PyTrilinos2017-12-06T20:45:52ZJames WillenbringMatrix Assembly Efficiency in PyTrilinos*Created by: michael-a-hansen*
Hello,
I have some questions about efficiently filling and updating a matrix with tools available to `PyTrilinos`. The problem I'm solving is very nonlinear and while the Jacobian matrix _structure_ is ...*Created by: michael-a-hansen*
Hello,
I have some questions about efficiently filling and updating a matrix with tools available to `PyTrilinos`. The problem I'm solving is very nonlinear and while the Jacobian matrix _structure_ is fixed (block tri-diagonal with large blocks), the elements themselves need to be recomputed frequently. Scraping tutorials and examples has led me to code such as the following, where `InsertGlobalValues` is called on an `EpetraCrsMatrix` in a Python loop over the rows. However, I observe this code is usually around 60x slower than assembling a `Scipy` sparse matrix via direct specification of full coordinate form.
Given a fixed Jacobian matrix structure, and capabilities available in `PyTrilinos`,
1. Is there a faster way to assemble the matrix than `A.InsertGlobalValues` on `EpetraCrsMatrix`? I think `VbrMatrix` may be helpful for my block structure but I haven't found a `PyTrilinos` example.
2. Given a `FillComplete`d matrix, is there an efficient way to replace its elements?
```
my_map = Epetra.Map(ndof, 0, comm)
A = Epetra.CrsMatrix(Epetra.Copy, my_map, 0)
for row, (cols, vals) in enumerate(rowmap): # cols and vals are _all_ elements in the row
A.InsertGlobalValues(row, vals, cols)
A.FillComplete()
```
### Environment
- Trilinos cloned at commit `b2341eff32 [Thu Oct 12 10:07:25 2017 -0600]`, built all packages including `PyTrilinos`.
- Python3.6
- Mac OS X 10.12.16, `Apple LLVM version 8.1.0 (clang-802.0.42)`, gcc 4.2.1
- Running in serial
https://gitlab.osti.gov/jmwille/Trilinos/-/issues/955PyTrilinos: move out SWIG detection to root cmake/2018-06-26T20:36:00ZJames WillenbringPyTrilinos: move out SWIG detection to root cmake/*Created by: aprokop*
ForTrilinos will use SWIG and thus this code could be shared by both.*Created by: aprokop*
ForTrilinos will use SWIG and thus this code could be shared by both.https://gitlab.osti.gov/jmwille/Trilinos/-/issues/891Set up automated Nightly testing for PyTrilinos2018-04-11T15:58:48ZJames WillenbringSet up automated Nightly testing for PyTrilinos*Created by: bartlettroscoe*
**CC:** @trilinos/framework, @wfspotz
**Description:**
Currently PyTrilinos is not under any automated testing that gets posted up to the Trilinos CDash site:
* testing.sandia.gov/cdash/
See the...*Created by: bartlettroscoe*
**CC:** @trilinos/framework, @wfspotz
**Description:**
Currently PyTrilinos is not under any automated testing that gets posted up to the Trilinos CDash site:
* testing.sandia.gov/cdash/
See the below email chain.
----
From: Bartlett, Roscoe A
Sent: Tuesday, November 29, 2016 4:10 PM
To: Spotz, William F
Cc: Willenbring, James M; Perschbacher, Brent M
Subject: RE: [Pytrilinos-regression] FAILED (c=1): Trilinos/PyTrilinos - Linux-GCC-4.7.2-MPI_RELEASE_DEBUG_SHARED_PT_CI - Continuous
Bill,
PyTrilinos was enabled by accident. See:
* https://github.com/trilinos/Trilinos/issues/482#issuecomment-263575023
* https://github.com/trilinos/Trilinos/commit/1b14dadb154a2f49e1097c91a0340d66c39306b6
It is not enabled in the correct PT CI build as shown here:
* http://testing.sandia.gov/cdash/index.php?project=Trilinos&parentid=2634468
Some work is going to need to be done before PyTrilinos can be built using the SEMS env and include in any automated testing. For example, currently, PyTrilinos is not tested in any automated Trilinos build uploaded to CDash:
* http://testing.sandia.gov/cdash/index.php?subproject=PyTrilinos&project=Trilinos&date=2016-11-28
Getting things set up to test PyTrilinos is something that you are going to need to take up with the Trilinos Framework team (i.e. Jim and Brent) and the SEMS team.
But at the very minimum, you should set up PyTrilinos testing on one of your machines where you have this working.
-Ross
----
From: Spotz, William F
Sent: Tuesday, November 29, 2016 4:04 PM
To: Bartlett, Roscoe A
Subject: Fwd: [Pytrilinos-regression] FAILED (c=1): Trilinos/PyTrilinos - Linux-GCC-4.7.2-MPI_RELEASE_DEBUG_SHARED_PT_CI - Continuous
Hi Ross,
So does “Pytrilinos-regression” include both of us?
If not, the configure errors were that
1) No python numpy module was found
2) The SWIG version, 1.3.40, was too old — required is 3.0.0
-Bill
----
From: CDash <trilinos-regression@sandia.gov>
Subject: [Pytrilinos-regression] FAILED (c=1): Trilinos/PyTrilinos - Linux-GCC-4.7.2-MPI_RELEASE_DEBUG_SHARED_PT_CI - Continuous
Date: November 29, 2016 at 1:13:33 AM MST
To: <pytrilinos-regression@software.sandia.gov>
Reply-To: <noreply@sandia.gov>
A submission to CDash for the project Trilinos has configure errors.
You have been identified as one of the authors who have checked in changes that are part of this submission or you are listed in the default contact list.
Details on the submission can be found at http://testing.sandia.gov/cdash/buildSummary.php?buildid=2633954
Project: Trilinos
SubProject: PyTrilinos
Site: crf450.srn.sandia.gov
Build Name: Linux-GCC-4.7.2-MPI_RELEASE_DEBUG_SHARED_PT_CI
Build Time: 2016-11-29T08:13:32 UTC
Type: Continuous
Configure errors: 1
*Configure*
Status: 1 (http://testing.sandia.gov/cdash/viewConfigure.php?buildid=2633954)
Output:
Configuring Trilinos build directory
-- PROJECT_SOURCE_DIR='/ascldap/users/rabartl/Trilinos.base/SEMSCIBuild/Trilinos'
-- PROJECT_BINARY_DIR='/home/rabartl/Trilinos.base/SEMSCIBuild/BUILD'
-- Trilinos_TRIBITS_DIR='/ascldap/users/rabartl/Trilinos.base/SE
-CDash on testing.sandia.gov
_______________________________________________
Pytrilinos-regression mailing list
Pytrilinos-regression@software.sandia.gov
https://software.sandia.gov/mailman/listinfo/pytrilinos-regression
https://gitlab.osti.gov/jmwille/Trilinos/-/issues/880PyTrilinos: tests failed for missing __init__.py2017-10-05T21:19:12ZJames WillenbringPyTrilinos: tests failed for missing __init__.py*Created by: sagitter*
Hi all.
A couple of `PyTrilinos` tests (`PyTrilinos_testIsorropia, PyTrilinos_testNOX_StatusTest`) are failing for missing `__init__.py` files:
```
Start 1571: PyTrilinos_testNOX_StatusTest
1571: T...*Created by: sagitter*
Hi all.
A couple of `PyTrilinos` tests (`PyTrilinos_testIsorropia, PyTrilinos_testNOX_StatusTest`) are failing for missing `__init__.py` files:
```
Start 1571: PyTrilinos_testNOX_StatusTest
1571: Test command: /usr/bin/python2.7 "testNOX_StatusTest.py" "--testharness"
1571: Test timeout computed to be: 2000
1571: Traceback (most recent call last):
1571: File "testNOX_StatusTest.py", line 68, in <module>
1571: NOX = fromPyTrilinosImport('NOX' , options.testharness)
1571: File "/builddir/build/BUILD/trilinos-12.8.1/Trilinos-trilinos-release-12-8-1/build/packages/PyTrilinos/test/testutil.py", line 100, in fromPyTrilinosImport
1571: PyTrilinosPkg = __import__(fullname, globals, locals)
1571: File "/builddir/build/BUILD/trilinos-12.8.1/Trilinos-trilinos-release-12-8-1/build/packages/PyTrilinos/src/PyTrilinos/NOX/__init__.py", line 49, in <module>
1571: ___init__ = swig_import_helper()
1571: File "/builddir/build/BUILD/trilinos-12.8.1/Trilinos-trilinos-release-12-8-1/build/packages/PyTrilinos/src/PyTrilinos/NOX/__init__.py", line 48, in swig_import_helper
1571: return importlib.import_module('___init__')
1571: File "/usr/lib64/python2.7/importlib/__init__.py", line 37, in import_module
1571: __import__(name)
1571: ImportError: No module named ___init__
1568/1571 Test #1570: PyTrilinos_testML_Preconditioner ............................................. Passed 0.31 sec
1569/1571 Test #1569: PyTrilinos_testML_PyMatrix ................................................... Passed 0.31 sec
1570/1571 Test #1571: PyTrilinos_testNOX_StatusTest ................................................***Failed Required regular expression not found.Regex=[End Result: TEST PASSED
] 0.13 sec
Start 1557: PyTrilinos_testIsorropia
1557: Test command: /usr/bin/python2.7 "testIsorropia.py" "--testharness"
1557: Test timeout computed to be: 2000
1557: Traceback (most recent call last):
1557: File "testIsorropia.py", line 55, in <module>
1557: Isorropia = fromPyTrilinosImport('Isorropia' , True)
1557: File "/builddir/build/BUILD/trilinos-12.8.1/Trilinos-trilinos-release-12-8-1/build/packages/PyTrilinos/test/testutil.py", line 100, in fromPyTrilinosImport
1557: PyTrilinosPkg = __import__(fullname, globals, locals)
1557: File "/builddir/build/BUILD/trilinos-12.8.1/Trilinos-trilinos-release-12-8-1/build/packages/PyTrilinos/src/PyTrilinos/Isorropia/__init__.py", line 32, in <module>
1557: ___init__ = swig_import_helper()
1557: File "/builddir/build/BUILD/trilinos-12.8.1/Trilinos-trilinos-release-12-8-1/build/packages/PyTrilinos/src/PyTrilinos/Isorropia/__init__.py", line 31, in swig_import_helper
1557: return importlib.import_module('___init__')
1557: File "/usr/lib64/python2.7/importlib/__init__.py", line 37, in import_module
1557: __import__(name)
1557: ImportError: No module named ___init__
1554/1571 Test #1557: PyTrilinos_testIsorropia .....................................................***Failed Required regular expression not found.Regex=[End Result: TEST PASSED
```
Build log: https://kojipkgs.fedoraproject.org//work/tasks/264/16560264/build.loghttps://gitlab.osti.gov/jmwille/Trilinos/-/issues/866PyTrilinos: libpytrilinos.so, undefined symbols2017-06-21T15:03:52ZJames WillenbringPyTrilinos: libpytrilinos.so, undefined symbols*Created by: sagitter*
Hi all.
`libpytrilinos.so` library has various undefined symbols:
```
$ ldd -r /usr/lib64/libpytrilinos.so.12.8.1
linux-vdso.so.1 (0x00007fff581e4000)
libtpetra.so.12 => /lib64/libtpetra.so.12 (0x00007f...*Created by: sagitter*
Hi all.
`libpytrilinos.so` library has various undefined symbols:
```
$ ldd -r /usr/lib64/libpytrilinos.so.12.8.1
linux-vdso.so.1 (0x00007fff581e4000)
libtpetra.so.12 => /lib64/libtpetra.so.12 (0x00007fc73aa3f000)
libepetraext.so.12 => /lib64/libepetraext.so.12 (0x00007fc73a70f000)
libepetra.so.12 => /lib64/libepetra.so.12 (0x00007fc73a3ba000)
libteuchoscomm.so.12 => /lib64/libteuchoscomm.so.12 (0x00007fc73a154000)
libteuchosparameterlist.so.12 => /lib64/libteuchosparameterlist.so.12 (0x00007fc739b3d000)
libteuchoscore.so.12 => /lib64/libteuchoscore.so.12 (0x00007fc7398e0000)
libstdc++.so.6 => /lib64/libstdc++.so.6 (0x00007fc739558000)
libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x00007fc739341000)
libc.so.6 => /lib64/libc.so.6 (0x00007fc738f7e000)
libtpetrakernels.so.12 => /lib64/libtpetrakernels.so.12 (0x00007fc738723000)
libtpetraclassicnodeapi.so.12 => /lib64/libtpetraclassicnodeapi.so.12 (0x00007fc738518000)
libteuchosnumerics.so.12 => /lib64/libteuchosnumerics.so.12 (0x00007fc7382f2000)
libteuchoskokkoscompat.so.12 => /lib64/libteuchoskokkoscompat.so.12 (0x00007fc7380e6000)
libkokkoscore.so.12 => /lib64/libkokkoscore.so.12 (0x00007fc737e86000)
libm.so.6 => /lib64/libm.so.6 (0x00007fc737b7c000)
libgomp.so.1 => /lib64/libgomp.so.1 (0x00007fc73794e000)
libtriutils.so.12 => /lib64/libtriutils.so.12 (0x00007fc7376fc000)
liblapack.so.3 => /lib64/liblapack.so.3 (0x00007fc736efc000)
libblas.so.3 => /lib64/libblas.so.3 (0x00007fc736ca5000)
libpthread.so.0 => /lib64/libpthread.so.0 (0x00007fc736a88000)
/lib64/ld-linux-x86-64.so.2 (0x0000555aa02b4000)
libdl.so.2 => /lib64/libdl.so.2 (0x00007fc736884000)
libgfortran.so.3 => /lib64/libgfortran.so.3 (0x00007fc736552000)
libquadmath.so.0 => /lib64/libquadmath.so.0 (0x00007fc736312000)
undefined symbol: PyDict_SetItem (/usr/lib64/libpytrilinos.so.12.8.1)
undefined symbol: PyExc_ValueError (/usr/lib64/libpytrilinos.so.12.8.1)
undefined symbol: PyExc_KeyError (/usr/lib64/libpytrilinos.so.12.8.1)
undefined symbol: PyDict_SetItemString (/usr/lib64/libpytrilinos.so.12.8.1)
undefined symbol: PyImport_ImportModule (/usr/lib64/libpytrilinos.so.12.8.1)
undefined symbol: PyType_IsSubtype (/usr/lib64/libpytrilinos.so.12.8.1)
undefined symbol: PyString_FromString (/usr/lib64/libpytrilinos.so.12.8.1)
undefined symbol: PyObject_SetAttrString (/usr/lib64/libpytrilinos.so.12.8.1)
undefined symbol: PyErr_Fetch (/usr/lib64/libpytrilinos.so.12.8.1)
undefined symbol: PyExc_RuntimeError (/usr/lib64/libpytrilinos.so.12.8.1)
undefined symbol: PyErr_Print (/usr/lib64/libpytrilinos.so.12.8.1)
undefined symbol: PyErr_SetString (/usr/lib64/libpytrilinos.so.12.8.1)
undefined symbol: PyObject_CallObject (/usr/lib64/libpytrilinos.so.12.8.1)
undefined symbol: PyCObject_AsVoidPtr (/usr/lib64/libpytrilinos.so.12.8.1)
undefined symbol: PyObject_IsInstance (/usr/lib64/libpytrilinos.so.12.8.1)
undefined symbol: PyErr_WriteUnraisable (/usr/lib64/libpytrilinos.so.12.8.1)
undefined symbol: _Py_ZeroStruct (/usr/lib64/libpytrilinos.so.12.8.1)
undefined symbol: PyImport_ImportModuleLevel (/usr/lib64/libpytrilinos.so.12.8.1)
undefined symbol: PyObject_Init (/usr/lib64/libpytrilinos.so.12.8.1)
undefined symbol: PyString_Format (/usr/lib64/libpytrilinos.so.12.8.1)
undefined symbol: _PyInstance_Lookup (/usr/lib64/libpytrilinos.so.12.8.1)
undefined symbol: _PyWeakref_CallableProxyType (/usr/lib64/libpytrilinos.so.12.8.1)
undefined symbol: PyDict_Next (/usr/lib64/libpytrilinos.so.12.8.1)
undefined symbol: PyInstance_Type (/usr/lib64/libpytrilinos.so.12.8.1)
undefined symbol: _PyObject_New (/usr/lib64/libpytrilinos.so.12.8.1)
undefined symbol: PyInt_FromLong (/usr/lib64/libpytrilinos.so.12.8.1)
undefined symbol: _Py_NoneStruct (/usr/lib64/libpytrilinos.so.12.8.1)
undefined symbol: PyErr_Clear (/usr/lib64/libpytrilinos.so.12.8.1)
undefined symbol: PyDict_New (/usr/lib64/libpytrilinos.so.12.8.1)
undefined symbol: PyInt_AsLong (/usr/lib64/libpytrilinos.so.12.8.1)
undefined symbol: PyObject_RichCompareBool (/usr/lib64/libpytrilinos.so.12.8.1)
undefined symbol: PySequence_GetItem (/usr/lib64/libpytrilinos.so.12.8.1)
undefined symbol: _Py_NotImplementedStruct (/usr/lib64/libpytrilinos.so.12.8.1)
undefined symbol: PySequence_Size (/usr/lib64/libpytrilinos.so.12.8.1)
undefined symbol: PyExc_TypeError (/usr/lib64/libpytrilinos.so.12.8.1)
undefined symbol: Py_BuildValue (/usr/lib64/libpytrilinos.so.12.8.1)
undefined symbol: PyType_Ready (/usr/lib64/libpytrilinos.so.12.8.1)
undefined symbol: PySequence_Concat (/usr/lib64/libpytrilinos.so.12.8.1)
undefined symbol: PyFloat_FromDouble (/usr/lib64/libpytrilinos.so.12.8.1)
undefined symbol: PyObject_IsTrue (/usr/lib64/libpytrilinos.so.12.8.1)
undefined symbol: PyDict_GetItemString (/usr/lib64/libpytrilinos.so.12.8.1)
undefined symbol: PyObject_Free (/usr/lib64/libpytrilinos.so.12.8.1)
undefined symbol: PyBool_FromLong (/usr/lib64/libpytrilinos.so.12.8.1)
undefined symbol: _Py_TrueStruct (/usr/lib64/libpytrilinos.so.12.8.1)
undefined symbol: _PyObject_GetDictPtr (/usr/lib64/libpytrilinos.so.12.8.1)
undefined symbol: PyTuple_GetItem (/usr/lib64/libpytrilinos.so.12.8.1)
undefined symbol: PyFloat_Type (/usr/lib64/libpytrilinos.so.12.8.1)
undefined symbol: PyExc_IndexError (/usr/lib64/libpytrilinos.so.12.8.1)
undefined symbol: _PyWeakref_ProxyType (/usr/lib64/libpytrilinos.so.12.8.1)
undefined symbol: PyObject_Malloc (/usr/lib64/libpytrilinos.so.12.8.1)
undefined symbol: PyFloat_AsDouble (/usr/lib64/libpytrilinos.so.12.8.1)
undefined symbol: PyTuple_SetItem (/usr/lib64/libpytrilinos.so.12.8.1)
undefined symbol: PyBool_Type (/usr/lib64/libpytrilinos.so.12.8.1)
undefined symbol: PyInstance_NewRaw (/usr/lib64/libpytrilinos.so.12.8.1)
undefined symbol: PyErr_Restore (/usr/lib64/libpytrilinos.so.12.8.1)
undefined symbol: PyObject_Type (/usr/lib64/libpytrilinos.so.12.8.1)
undefined symbol: PyObject_Call (/usr/lib64/libpytrilinos.so.12.8.1)
undefined symbol: PyArg_UnpackTuple (/usr/lib64/libpytrilinos.so.12.8.1)
undefined symbol: PySequence_Check (/usr/lib64/libpytrilinos.so.12.8.1)
undefined symbol: PyString_AsString (/usr/lib64/libpytrilinos.so.12.8.1)
undefined symbol: PyLong_FromVoidPtr (/usr/lib64/libpytrilinos.so.12.8.1)
undefined symbol: PyCapsule_Import (/usr/lib64/libpytrilinos.so.12.8.1)
undefined symbol: PyObject_GetAttr (/usr/lib64/libpytrilinos.so.12.8.1)
undefined symbol: PyObject_GetAttrString (/usr/lib64/libpytrilinos.so.12.8.1)
undefined symbol: PyDict_GetItem (/usr/lib64/libpytrilinos.so.12.8.1)
undefined symbol: PyObject_CallFunctionObjArgs (/usr/lib64/libpytrilinos.so.12.8.1)
undefined symbol: PyTuple_New (/usr/lib64/libpytrilinos.so.12.8.1)
undefined symbol: PyObject_Str (/usr/lib64/libpytrilinos.so.12.8.1)
undefined symbol: PyErr_Format (/usr/lib64/libpytrilinos.so.12.8.1)
undefined symbol: PyString_FromFormat (/usr/lib64/libpytrilinos.so.12.8.1)
undefined symbol: PyExc_AttributeError (/usr/lib64/libpytrilinos.so.12.8.1)
undefined symbol: PyExc_ImportError (/usr/lib64/libpytrilinos.so.12.8.1)
undefined symbol: PyTuple_Size (/usr/lib64/libpytrilinos.so.12.8.1)
undefined symbol: PyErr_Occurred (/usr/lib64/libpytrilinos.so.12.8.1)
undefined symbol: PyCObject_Type (/usr/lib64/libpytrilinos.so.12.8.1)
undefined symbol: PyString_ConcatAndDel (/usr/lib64/libpytrilinos.so.12.8.1)
undefined symbol: PyObject_GenericGetAttr (/usr/lib64/libpytrilinos.so.12.8.1)
```
It's built on Fedora 24 with `Python2.7`; should not it be linked to `libpython.so`?
Build log: https://kojipkgs.fedoraproject.org//work/tasks/5595/16545595/build.loghttps://gitlab.osti.gov/jmwille/Trilinos/-/issues/806PyTrilinos: Contributing by writing wrappers for missing functions2016-11-10T22:23:46ZJames WillenbringPyTrilinos: Contributing by writing wrappers for missing functions*Created by: hakeemo*
As I gradually build my application using pyTrilinos, I find myself wanting to use functions in Trilinos which have no python interface. I would like to have some guidance in how to implement a python wrapper for a...*Created by: hakeemo*
As I gradually build my application using pyTrilinos, I find myself wanting to use functions in Trilinos which have no python interface. I would like to have some guidance in how to implement a python wrapper for a specific function. As a concrete example I would like to wrap ML_Epetra::EpetraMatrix2MLMatrix. How can this be done? I would gladly start pull requests with my updated code.
@wfspotz https://gitlab.osti.gov/jmwille/Trilinos/-/issues/780STK doc problem2016-12-02T19:53:31ZJames WillenbringSTK doc problem*Created by: VictorEijkhout*
File cmake/PyTrilinos/PyTrilinosConfig.cmake
contains a line:
INCLUDE("${CMAKE_CURRENT_LIST_DIR}/../STKDoc_tests/STKDoc_testsConfig.cmake")
referring to a non-existing file. This does not impede tri...*Created by: VictorEijkhout*
File cmake/PyTrilinos/PyTrilinosConfig.cmake
contains a line:
INCLUDE("${CMAKE_CURRENT_LIST_DIR}/../STKDoc_tests/STKDoc_testsConfig.cmake")
referring to a non-existing file. This does not impede trilinos installation, but it trips up for instance DealII.
[Archive.zip](https://github.com/trilinos/Trilinos/files/571715/Archive.zip)
Victor.
PS why doesn't your ticket system accept files with extension that you generate by the dozen? That kinda makes it hard to attach files. I've packaged some log files and zipped them as attachment to this ticket.https://gitlab.osti.gov/jmwille/Trilinos/-/issues/652Building PyTrilinos on Windows2016-09-25T22:05:26ZJames WillenbringBuilding PyTrilinos on Windows*Created by: gpkc*
Hi,
Have anyone been able to build PyTrilinos on Windows?
I'm able to build other packages such as Epetra, AztecOO... But I can't seem to find a way to build PyTrilinos. I've been struggling for some time. First I was...*Created by: gpkc*
Hi,
Have anyone been able to build PyTrilinos on Windows?
I'm able to build other packages such as Epetra, AztecOO... But I can't seem to find a way to build PyTrilinos. I've been struggling for some time. First I was facing a few path issues. CMAKE was finding my numpy path and passing it to the `ASSERT_DEFINED` and `INCLUDE_DIRECTORIES` macros, but the path was being passed with backslashes (something like C:\Python27...). So I was getting a CMAKE error telling me that this variable had an invalid scape sequence, in this case, '\P'. I changed those macros to functions and those erros vanished. But now I'm now stuck with those other CMAKE errors, and I have no idea how to get rid of them:
```
Configuring individual enabled Trilinos packages ...
Processing enabled package: Teuchos (Libs)
CMake Error at cmake/tribits/core/package_arch/TribitsPackageSetupCompilerFlags.cmake:135 (TRIBITS_SETUP_STRONG_COMPILE_WARNINGS):
TRIBITS_SETUP_STRONG_COMPILE_WARNINGS Function invoked with incorrect
arguments for function named: TRIBITS_SETUP_STRONG_COMPILE_WARNINGS
Call Stack (most recent call first):
cmake/tribits/core/package_arch/TribitsPackageMacros.cmake:230 (TRIBITS_SETUP_COMPILER_FLAGS)
packages/teuchos/CMakeLists.txt:19 (TRIBITS_PACKAGE_DECL)
CMake Error at cmake/tribits/core/utils/AssertDefined.cmake:79 (MESSAGE):
Error, the variable PARSE_CLEANED is not defined!
Call Stack (most recent call first):
cmake/tribits/core/package_arch/TribitsPackageSetupCompilerFlags.cmake:140 (ASSERT_DEFINED)
cmake/tribits/core/package_arch/TribitsPackageMacros.cmake:230 (TRIBITS_SETUP_COMPILER_FLAGS)
packages/teuchos/CMakeLists.txt:19 (TRIBITS_PACKAGE_DECL)
CMake Error at cmake/tribits/core/utils/AssertDefined.cmake:79 (MESSAGE):
Error, the variable TeuchosCore_ENABLE_Boost is not defined!
Call Stack (most recent call first):
packages/teuchos/CMakeLists.txt:72 (ASSERT_DEFINED)
C++ compiler does NOT support __attribute__((constructor)) syntax
C++ compiler does NOT support __attribute__((weak)) syntax and testing weak functions
C++ compiler does NOT support #pragma weak syntax and testing weak functions
Processing enabled package: Epetra (Libs)
CMake Error at cmake/tribits/core/package_arch/TribitsPackageSetupCompilerFlags.cmake:135 (TRIBITS_SETUP_STRONG_COMPILE_WARNINGS):
TRIBITS_SETUP_STRONG_COMPILE_WARNINGS Function invoked with incorrect
arguments for function named: TRIBITS_SETUP_STRONG_COMPILE_WARNINGS
Call Stack (most recent call first):
cmake/tribits/core/package_arch/TribitsPackageMacros.cmake:230 (TRIBITS_SETUP_COMPILER_FLAGS)
cmake/tribits/core/package_arch/TribitsPackageMacros.cmake:320 (TRIBITS_PACKAGE_DECL)
packages/epetra/CMakeLists.txt:3 (TRIBITS_PACKAGE)
CMake Error at cmake/tribits/core/utils/AssertDefined.cmake:79 (MESSAGE):
Error, the variable PARSE_CLEANED is not defined!
Call Stack (most recent call first):
cmake/tribits/core/package_arch/TribitsPackageSetupCompilerFlags.cmake:140 (ASSERT_DEFINED)
cmake/tribits/core/package_arch/TribitsPackageMacros.cmake:230 (TRIBITS_SETUP_COMPILER_FLAGS)
cmake/tribits/core/package_arch/TribitsPackageMacros.cmake:320 (TRIBITS_PACKAGE_DECL)
packages/epetra/CMakeLists.txt:3 (TRIBITS_PACKAGE)
You have called ADD_LIBRARY for library epetra without any source files. This typically indicates a problem with your CMakeLists.txt file
Processing enabled package: Triutils (Libs)
CMake Error at cmake/tribits/core/package_arch/TribitsPackageSetupCompilerFlags.cmake:135 (TRIBITS_SETUP_STRONG_COMPILE_WARNINGS):
TRIBITS_SETUP_STRONG_COMPILE_WARNINGS Function invoked with incorrect
arguments for function named: TRIBITS_SETUP_STRONG_COMPILE_WARNINGS
Call Stack (most recent call first):
cmake/tribits/core/package_arch/TribitsPackageMacros.cmake:230 (TRIBITS_SETUP_COMPILER_FLAGS)
cmake/tribits/core/package_arch/TribitsPackageMacros.cmake:320 (TRIBITS_PACKAGE_DECL)
packages/triutils/CMakeLists.txt:3 (TRIBITS_PACKAGE)
CMake Error at cmake/tribits/core/utils/AssertDefined.cmake:79 (MESSAGE):
Error, the variable PARSE_CLEANED is not defined!
Call Stack (most recent call first):
cmake/tribits/core/package_arch/TribitsPackageSetupCompilerFlags.cmake:140 (ASSERT_DEFINED)
cmake/tribits/core/package_arch/TribitsPackageMacros.cmake:230 (TRIBITS_SETUP_COMPILER_FLAGS)
cmake/tribits/core/package_arch/TribitsPackageMacros.cmake:320 (TRIBITS_PACKAGE_DECL)
packages/triutils/CMakeLists.txt:3 (TRIBITS_PACKAGE)
You have called ADD_LIBRARY for library triutils without any source files. This typically indicates a problem with your CMakeLists.txt file
Processing enabled package: EpetraExt (Libs)
CMake Error at cmake/tribits/core/package_arch/TribitsPackageSetupCompilerFlags.cmake:135 (TRIBITS_SETUP_STRONG_COMPILE_WARNINGS):
TRIBITS_SETUP_STRONG_COMPILE_WARNINGS Function invoked with incorrect
arguments for function named: TRIBITS_SETUP_STRONG_COMPILE_WARNINGS
Call Stack (most recent call first):
cmake/tribits/core/package_arch/TribitsPackageMacros.cmake:230 (TRIBITS_SETUP_COMPILER_FLAGS)
cmake/tribits/core/package_arch/TribitsPackageMacros.cmake:320 (TRIBITS_PACKAGE_DECL)
packages/epetraext/CMakeLists.txt:7 (TRIBITS_PACKAGE)
CMake Error at cmake/tribits/core/utils/AssertDefined.cmake:79 (MESSAGE):
Error, the variable PARSE_CLEANED is not defined!
Call Stack (most recent call first):
cmake/tribits/core/package_arch/TribitsPackageSetupCompilerFlags.cmake:140 (ASSERT_DEFINED)
cmake/tribits/core/package_arch/TribitsPackageMacros.cmake:230 (TRIBITS_SETUP_COMPILER_FLAGS)
cmake/tribits/core/package_arch/TribitsPackageMacros.cmake:320 (TRIBITS_PACKAGE_DECL)
packages/epetraext/CMakeLists.txt:7 (TRIBITS_PACKAGE)
You have called ADD_LIBRARY for library epetraext without any source files. This typically indicates a problem with your CMakeLists.txt file
Processing enabled package: AztecOO (Libs)
CMake Error at cmake/tribits/core/package_arch/TribitsPackageSetupCompilerFlags.cmake:135 (TRIBITS_SETUP_STRONG_COMPILE_WARNINGS):
TRIBITS_SETUP_STRONG_COMPILE_WARNINGS Function invoked with incorrect
arguments for function named: TRIBITS_SETUP_STRONG_COMPILE_WARNINGS
Call Stack (most recent call first):
cmake/tribits/core/package_arch/TribitsPackageMacros.cmake:230 (TRIBITS_SETUP_COMPILER_FLAGS)
cmake/tribits/core/package_arch/TribitsPackageMacros.cmake:320 (TRIBITS_PACKAGE_DECL)
packages/aztecoo/CMakeLists.txt:14 (TRIBITS_PACKAGE)
CMake Error at cmake/tribits/core/utils/AssertDefined.cmake:79 (MESSAGE):
Error, the variable PARSE_CLEANED is not defined!
Call Stack (most recent call first):
cmake/tribits/core/package_arch/TribitsPackageSetupCompilerFlags.cmake:140 (ASSERT_DEFINED)
cmake/tribits/core/package_arch/TribitsPackageMacros.cmake:230 (TRIBITS_SETUP_COMPILER_FLAGS)
cmake/tribits/core/package_arch/TribitsPackageMacros.cmake:320 (TRIBITS_PACKAGE_DECL)
packages/aztecoo/CMakeLists.txt:14 (TRIBITS_PACKAGE)
You have called ADD_LIBRARY for library aztecoo without any source files. This typically indicates a problem with your CMakeLists.txt file
Processing enabled package: Ifpack (Libs)
CMake Error at cmake/tribits/core/package_arch/TribitsPackageSetupCompilerFlags.cmake:135 (TRIBITS_SETUP_STRONG_COMPILE_WARNINGS):
TRIBITS_SETUP_STRONG_COMPILE_WARNINGS Function invoked with incorrect
arguments for function named: TRIBITS_SETUP_STRONG_COMPILE_WARNINGS
Call Stack (most recent call first):
cmake/tribits/core/package_arch/TribitsPackageMacros.cmake:230 (TRIBITS_SETUP_COMPILER_FLAGS)
cmake/tribits/core/package_arch/TribitsPackageMacros.cmake:320 (TRIBITS_PACKAGE_DECL)
packages/ifpack/CMakeLists.txt:7 (TRIBITS_PACKAGE)
CMake Error at cmake/tribits/core/utils/AssertDefined.cmake:79 (MESSAGE):
Error, the variable PARSE_CLEANED is not defined!
Call Stack (most recent call first):
cmake/tribits/core/package_arch/TribitsPackageSetupCompilerFlags.cmake:140 (ASSERT_DEFINED)
cmake/tribits/core/package_arch/TribitsPackageMacros.cmake:230 (TRIBITS_SETUP_COMPILER_FLAGS)
cmake/tribits/core/package_arch/TribitsPackageMacros.cmake:320 (TRIBITS_PACKAGE_DECL)
packages/ifpack/CMakeLists.txt:7 (TRIBITS_PACKAGE)
You have called ADD_LIBRARY for library ifpack without any source files. This typically indicates a problem with your CMakeLists.txt file
Processing enabled package: PyTrilinos (Libs)
CMake Error at cmake/tribits/core/package_arch/TribitsPackageSetupCompilerFlags.cmake:135 (TRIBITS_SETUP_STRONG_COMPILE_WARNINGS):
TRIBITS_SETUP_STRONG_COMPILE_WARNINGS Function invoked with incorrect
arguments for function named: TRIBITS_SETUP_STRONG_COMPILE_WARNINGS
Call Stack (most recent call first):
cmake/tribits/core/package_arch/TribitsPackageMacros.cmake:230 (TRIBITS_SETUP_COMPILER_FLAGS)
cmake/tribits/core/package_arch/TribitsPackageMacros.cmake:320 (TRIBITS_PACKAGE_DECL)
packages/PyTrilinos/CMakeLists.txt:48 (TRIBITS_PACKAGE)
CMake Error at cmake/tribits/core/utils/AssertDefined.cmake:79 (MESSAGE):
Error, the variable PARSE_CLEANED is not defined!
Call Stack (most recent call first):
cmake/tribits/core/package_arch/TribitsPackageSetupCompilerFlags.cmake:140 (ASSERT_DEFINED)
cmake/tribits/core/package_arch/TribitsPackageMacros.cmake:230 (TRIBITS_SETUP_COMPILER_FLAGS)
cmake/tribits/core/package_arch/TribitsPackageMacros.cmake:320 (TRIBITS_PACKAGE_DECL)
packages/PyTrilinos/CMakeLists.txt:48 (TRIBITS_PACKAGE)
```
Those errors appear only when I activate the PyTrilinos package.
I've followed [this tutorial](https://github.com/INMOST-DEV/INMOST/wiki/0207-Compilation-Trilinos-Windows) and adapted it to my needs using VS2013, and also installed [SWIGWIN](http://prdownloads.sourceforge.net/swig/swigwin-3.0.10.zip).
https://gitlab.osti.gov/jmwille/Trilinos/-/issues/528PyTrilinos NOX-PETSc interface build issues2016-12-02T18:43:08ZJames WillenbringPyTrilinos NOX-PETSc interface build issues*Created by: mhoemmen*
@leonavery writes in #524:
> The second problem is with PyTrilinos, specifcally with the NOX-PETSc interface. During configuration, there are errors from SWIG about several header files not being found. These hea...*Created by: mhoemmen*
@leonavery writes in #524:
> The second problem is with PyTrilinos, specifcally with the NOX-PETSc interface. During configuration, there are errors from SWIG about several header files not being found. These headers are present in the source distribution at trilinos-12.6.3-Source/packages/nox/src-petsc, but apparently swig is not told to look for headers there. The same problem occurs during compilation. Compilation of several c++ files fails, because they are unable to find the same headers that swig failed to find. g++ is passed a long list of -I flags for this compilation, but there is no -I/trilinos-12.6.3-Source/packages/nox/src-petsc in the list. I don't know enough about cmake to figure out how it produces the list of include directories, but apparently this one is being left out for PyTrilinos. (I'm now trying to work around it with CMAKE_CXX_FLAGS.)
This is with gcc-6.1.0.