Trilinos issueshttps://gitlab.osti.gov/jmwille/Trilinos/-/issues2017-06-27T14:51:00Zhttps://gitlab.osti.gov/jmwille/Trilinos/-/issues/1341Eliminate warnings in CI build coming from mpi.h with GCC 4.9.3 and OpenMPI f...2017-06-27T14:51:00ZJames WillenbringEliminate warnings in CI build coming from mpi.h with GCC 4.9.3 and OpenMPI from 1.6.5*Created by: bartlettroscoe*
**Next Action Status:**
Adding `-isystem` for OpenMPI 1.6. include dir makes warnings go away locally but not for CTest -S script. Asked SEMS if they could patch mpi.h file (but unknown when that might h...*Created by: bartlettroscoe*
**Next Action Status:**
Adding `-isystem` for OpenMPI 1.6. include dir makes warnings go away locally but not for CTest -S script. Asked SEMS if they could patch mpi.h file (but unknown when that might happen). Next: Switch CI build to GCC 4.8.4 which does not emit the warnings?
**CC:** @trilinos/framework
**Description:**
With the upgrade to GCC 4.9.3 (see #1002), we are now getting a lot of warnings from OpenMPI 1.6.5 headers like:
```
In file included from /projects/sems/install/rhel6-x86_64/sems/compiler/gcc/4.9.3/openmpi/1.6.5/include/mpi.h:253:0,
from /scratch/rabartl/Trilinos.base/SEMSCIBuild/Trilinos/packages/teuchos/core/src/Teuchos_Time.hpp:56,
from /scratch/rabartl/Trilinos.base/SEMSCIBuild/Trilinos/packages/teuchos/core/src/Teuchos_Time.cpp:45:
/projects/sems/install/rhel6-x86_64/sems/compiler/gcc/4.9.3/openmpi/1.6.5/include/mpi_portable_platform.h:374:34: warning: invalid suffix on literal; C++11 requires a space between literal and string macro [-Wliteral-suffix]
_STRINGIFY(__GNUC__)"."_STRINGIFY(__GNUC_MINOR__)"."_STRINGIFY(__GNUC_PATCHLEVEL__)
^
/projects/sems/install/rhel6-x86_64/sems/compiler/gcc/4.9.3/openmpi/1.6.5/include/mpi_portable_platform.h:374:63: warning: invalid suffix on literal; C++11 requires a space between literal and string macro [-Wliteral-suffix]
_STRINGIFY(__GNUC__)"."_STRINGIFY(__GNUC_MINOR__)"."_STRINGIFY(__GNUC_PATCHLEVEL__)
^
```
such as you see, for example, in this CI iteration:
* http://testing.sandia.gov/cdash/viewBuildError.php?type=1&buildid=2902564
Looking at the new "Clean" build
Linux-gcc-4.9.3-MPI_Release_gcc_4.9.3_openmpi_1.8.7_DEV targeted for SIERRA, for example, at:
* http://testing.sandia.gov/cdash/index.php?project=Trilinos&parentid=2901291
perhaps our CI build should be upgraded to OpenMPI 1.8.7?
In any case, this story is to make these warnings go away so they don't spam Trilinos developers and CDash.https://gitlab.osti.gov/jmwille/Trilinos/-/issues/931emails are not being posted to MueLu or Ifpack2's developer's list2016-12-15T01:09:54ZJames Willenbringemails are not being posted to MueLu or Ifpack2's developer's list*Created by: jhux2*
@jwillenbring Emails to the MueLu developer's list are not being posted, and they are not showing up in the archive.*Created by: jhux2*
@jwillenbring Emails to the MueLu developer's list are not being posted, and they are not showing up in the archive.https://gitlab.osti.gov/jmwille/Trilinos/-/issues/101Enable MKL TPL but then CMake Reports BLAS Not Found2017-10-22T19:03:44ZJames WillenbringEnable MKL TPL but then CMake Reports BLAS Not Found*Created by: nmhamster*
Probably not doing this correctly. I have enabled the MKL TPL but when CMake is busy configuring it then reports BLAS is not found. Given that MKL provides BLAS routines at good performance, should this error occ...*Created by: nmhamster*
Probably not doing this correctly. I have enabled the MKL TPL but when CMake is busy configuring it then reports BLAS is not found. Given that MKL provides BLAS routines at good performance, should this error occur? Is correct to disable BLAS if I am using MKL?
```
Processing enabled TPL: MKL (enabled explicitly, disable with -DTPL_ENABLE_MKL=OFF)
-- Searching for libs in MKL_LIBRARY_DIRS='/home/projects/x86-64-knl/intel/compilers/2016/compilers_and_libraries_2016.1.150/linux/mkl/lib/intel64'
-- Searching for a lib in the set "mkl_rt":
-- Searching for lib 'mkl_rt' ...
-- Found lib '/home/projects/x86-64-knl/intel/compilers/2016/compilers_and_libraries_2016.1.150/linux/mkl/lib/intel64/libmkl_rt.so'
-- TPL_MKL_LIBRARIES='/home/projects/x86-64-knl/intel/compilers/2016/compilers_and_libraries_2016.1.150/linux/mkl/lib/intel64/libmkl_rt.so'
-- Searching for headers in MKL_INCLUDE_DIRS='/home/projects/x86-64-knl/intel/compilers/2016/compilers_and_libraries_2016.1.150/linux/mkl/lib/intel64'
-- Searching for a header file in the set "mkl.h":
-- Searching for header 'mkl.h' ...
-- Found header '/home/projects/x86-64-knl/intel/compilers/2016/compilers_and_libraries_2016.1.150/linux/mkl/include/mkl.h'
-- Found TPL 'MKL' include dirs '/home/projects/x86-64-knl/intel/compilers/2016/compilers_and_libraries_2016.1.150/linux/mkl/include'
-- TPL_MKL_INCLUDE_DIRS='/home/projects/x86-64-knl/intel/compilers/2016/compilers_and_libraries_2016.1.150/linux/mkl/include'
Processing enabled TPL: Pthread (enabled explicitly, disable with -DTPL_ENABLE_Pthread=OFF)
-- Looking for include file pthread.h
-- Looking for include file pthread.h - found
-- Looking for pthread_create
-- Looking for pthread_create - found
-- Found Threads: TRUE
Processing enabled TPL: MPI (enabled explicitly, disable with -DTPL_ENABLE_MPI=OFF)
Processing enabled TPL: BLAS (enabled by TeuchosNumerics, disable with -DTPL_ENABLE_BLAS=OFF)
-- Searching for libs in BLAS_LIBRARY_DIRS=''
-- Searching for a lib in the set "blas blas_win32":
-- Searching for lib 'blas' ...
-- Searching for lib 'blas_win32' ...
-- ERROR: Did not find a lib in the lib set "blas blas_win32" for the TPL 'BLAS'!
-- ERROR: Could not find the libraries for the TPL 'BLAS'!
-- TIP: If the TPL 'BLAS' is on your system then you can set:
-DBLAS_LIBRARY_DIRS='<dir0>;<dir1>;...'
to point to the directories where these libraries may be found.
Or, just set:
-DTPL_BLAS_LIBRARIES='<path-to-libs0>;<path-to-libs1>;...'
to point to the full paths for the libraries which will
bypass any search for libraries and these libraries will be used without
question in the build. (But this will result in a build-time error
if not all of the necessary symbols are found.)
-- ERROR: Failed finding all of the parts of TPL 'BLAS' (see above), Aborting!
-- NOTE: The find module file for this failed TPL 'BLAS' is:
/home/sdhammo/git/trilinos-github-repo/cmake/tribits/common_tpls/FindTPLBLAS.cmake
which is pointed to in the file:
/home/sdhammo/git/trilinos-github-repo/TPLsList.cmake
TIP: One way to get past the configure failure for the
TPL 'BLAS' is to simply disable it with:
-DTPL_ENABLE_BLAS=OFF
which will disable it and will recursively disable all of the
downstream packages that have required dependencies on it, including
the package 'TeuchosNumerics' which triggered its enable.
When you reconfigure, just grep the cmake stdout for 'BLAS'
and then follow the disables that occur as a result to see what impact
this TPL disable has on the configuration of Trilinos.
CMake Error at cmake/tribits/core/package_arch/TribitsProcessEnabledTpl.cmake:127 (MESSAGE):
ERROR: TPL_BLAS_NOT_FOUND=TRUE, aborting!
Call Stack (most recent call first):
cmake/tribits/core/package_arch/TribitsGlobalMacros.cmake:1556 (TRIBITS_PROCESS_ENABLED_TPL)
cmake/tribits/core/package_arch/TribitsProjectImpl.cmake:209 (TRIBITS_PROCESS_ENABLED_TPLS)
cmake/tribits/core/package_arch/TribitsProject.cmake:93 (TRIBITS_PROJECT_IMPL)
CMakeLists.txt:90 (TRIBITS_PROJECT)
```
https://gitlab.osti.gov/jmwille/Trilinos/-/issues/910Failing MueLu tests in CI build starting 12/7/20162016-12-09T20:25:26ZJames WillenbringFailing MueLu tests in CI build starting 12/7/2016*Created by: bartlettroscoe*
**CC:** @trilinos/framework, @trilinos/muelu
**Description:**
A push last night broke two MueLu tests. The most current CI build still shows the failures:
* http://testing.sandia.gov/cdash/index.php?proj...*Created by: bartlettroscoe*
**CC:** @trilinos/framework, @trilinos/muelu
**Description:**
A push last night broke two MueLu tests. The most current CI build still shows the failures:
* http://testing.sandia.gov/cdash/index.php?project=Trilinos&parentid=2646684&filtercount=3&showfilters=1&field1=groupname&compare1=61&value1=Continuous&field2=buildstarttime&compare2=84&value2=now&filtercombine=and
No one can use the checkin-test-sems.sh script to push while these tests are failing (unless they disable these tests which is what I did last night).https://gitlab.osti.gov/jmwille/Trilinos/-/issues/1929Failing Tpetra and Xpetra tests in CI build from commits pushed on 10/31/20172017-11-01T23:40:25ZJames WillenbringFailing Tpetra and Xpetra tests in CI build from commits pushed on 10/31/2017*Created by: bartlettroscoe*
**Next Action Status:**
Decide if to fix or backout the commits ...
**CC:** @trilinos/framework, @trilinos/tpetra, @trilinos/xpetra, @DrBooom
**Description:**
After the push of the commits:
`...*Created by: bartlettroscoe*
**Next Action Status:**
Decide if to fix or backout the commits ...
**CC:** @trilinos/framework, @trilinos/tpetra, @trilinos/xpetra, @DrBooom
**Description:**
After the push of the commits:
```
7ba1c78: Tpetra: put CheckImportValidity blocks in each of the Import constructors.
Author: Chris Luchini <cbluchi@sandia.gov>
Date: Tue Oct 31 13:30:01 2017 -0600
M packages/tpetra/core/src/Tpetra_Import_def.hpp
f66ede7: Tpetra: Clean up the CheckImportValidity routine
Author: Chris Luchini <cbluchi@sandia.gov>
Date: Tue Oct 31 13:07:12 2017 -0600
M packages/tpetra/core/src/Tpetra_Import_Util.hpp
```
shown at:
* https://testing-vm.sandia.gov/cdash/viewNotes.php?buildid=3139970#!#note1
we are now seeing 7 failing Tpetra tests and 2 failing Xpetra tests as shown at:
* https://testing-vm.sandia.gov/cdash/index.php?project=Trilinos&parentid=3139969
This corresponds to the logged push:
```
Tue Oct 31 13:34:22 MDT 2017
commit 7ba1c78b3d8208635bead45a867d1c2038d15f87
Author: Chris Luchini <cbluchi@sandia.gov>
AuthorDate: Tue Oct 31 13:30:01 2017 -0600
Commit: Chris Luchini <cbluchi@sandia.gov>
CommitDate: Tue Oct 31 13:30:17 2017 -0600
Tpetra: put CheckImportValidity blocks in each of the Import constructors.
Commits pushed:
7ba1c78 Tpetra: put CheckImportValidity blocks in each of the Import constructors.
f66ede7 Tpetra: Clean up the CheckImportValidity routine
```
(Does not look like checkin-test-sems.sh script was used to test and push.)
https://gitlab.osti.gov/jmwille/Trilinos/-/issues/3306Failure of ATDM build script on waterman2019-01-09T23:48:45ZJames WillenbringFailure of ATDM build script on waterman*Created by: keitat*
I am seeing the latest version of ATDM build script is not working on waterman.
## Expectations
I am following the instruction of budding on internal machines, but it's not working.
## Current Behavior
[kn...*Created by: keitat*
I am seeing the latest version of ATDM build script is not working on waterman.
## Expectations
I am following the instruction of budding on internal machines, but it's not working.
## Current Behavior
[knteran@waterman11 buildTrilinos]$ source $TRILINOS_DIR/cmake/std/atdm/load-env.sh kt_cuda
Error, hostname = 'waterman11' not recognized as a known ATDM system name!
## Steps to Reproduce
```
module load devpack/20180517/openmpi/3.1.0/gcc/7.2.0/cuda/9.2.88
export TRILINOS_DIR=your directory
source $TRILINOS_DIR/cmake/std/atdm/load-env.sh job name
```
## Your Environment
```
[knteran@waterman11 buildTrilinos]$ module list
Currently Loaded Modulefiles:
1) binutils/2.30.0 8) valgrind/3.12.0 15) pnetcdf-exo/1.9.0/openmpi/3.1.0/gcc/7.2.0/cuda/9.2.88
2) gcc/7.2.0 9) openblas/0.2.20/gcc/7.2.0 16) netcdf-exo/4.6.1/openmpi/3.1.0/gcc/7.2.0/cuda/9.2.88
3) cuda/9.2.88 10) metis/5.0.1/gcc/7.2.0 17) parmetis/4.0.3/openmpi/3.1.0/gcc/7.2.0/cuda/9.2.88
4) java/ibm/sdk/8.0.0 11) zlib/1.2.8 18) boost/1.65.1/gcc/7.2.0
5) numa/2.0.11 12) hdf5/1.8.20/openmpi/3.1.0/gcc/7.2.0/cuda/9.2.88 19) superlu-dist/4.3.0/openmpi/3.1.0/gcc/7.2.0/cuda/9.2.88
6) openmpi/3.1.0/gcc/7.2.0/cuda/9.2.88 13) cgns/20180517/openmpi/3.1.0/gcc/7.2.0/cuda/9.2.88 20) devpack/20180517/openmpi/3.1.0/gcc/7.2.0/cuda/9.2.88
7) cmake/3.6.2 14) matio/1.5.11/gcc/7.2.0
```https://gitlab.osti.gov/jmwille/Trilinos/-/issues/1823Fill out CONTRIBUTING.md2017-11-08T17:59:06ZJames WillenbringFill out CONTRIBUTING.md*Created by: jmgate*
A the moment, `CONTRIBUTING.md` just has some placeholder text in it. We need to fill it out such that potential contributors understand what is expected when interacting with Trilinos. I can take a crack at this,...*Created by: jmgate*
A the moment, `CONTRIBUTING.md` just has some placeholder text in it. We need to fill it out such that potential contributors understand what is expected when interacting with Trilinos. I can take a crack at this, but I won't be able to start on it till late next week.
@jwillenbring, @bmpersc, any requests as to content?
@trilinos/framework https://gitlab.osti.gov/jmwille/Trilinos/-/issues/3692Fortran compiler check fails2018-11-08T18:01:16ZJames WillenbringFortran compiler check fails*Created by: teamblubee*
<!---
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: teamblubee*
<!---
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.
-->
@trilinos/<teamName>
<!---
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.
-->
## Expectations
<!---
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
I am trying to use the Ninja generator to compile Trilinos using the newly open source Fortran compiler; Flang: https://github.com/flang-compiler/flang
The cmake test fails
```shell
Probing the environment ...
-- USE_XSDK_DEFAULTS='FALSE'
-- BUILD_SHARED_LIBS='FALSE'
-- CMAKE_BUILD_TYPE='RELEASE'
-- CMAKE_C_COMPILER_ID='Clang'
-- CMAKE_C_COMPILER_VERSION='5.0.1'
-- CMAKE_CXX_COMPILER_ID='Clang'
-- CMAKE_CXX_COMPILER_VERSION='5.0.1'
-- The Fortran compiler identification is Flang 99.99.1
-- Check for working Fortran compiler: /usr/local/bin/flang
-- Check for working Fortran compiler: /usr/local/bin/flang -- broken
CMake Error at /usr/local/share/cmake/Modules/CMakeTestFortranCompiler.cmake:45 (message):
The Fortran compiler
"/usr/local/bin/flang"
is not able to compile a simple test program.
It fails with the following output:
Change Dir: /wrkdirs/usr/ports/math/trilinos/work/.build/CMakeFiles/CMakeTmp
Run Build Command:"/usr/local/bin/ninja" "cmTC_2dfa4"
[1/4] Building Fortran preprocessed CMakeFiles/cmTC_2dfa4.dir/testFortranCompiler.f-pp.f
FAILED: CMakeFiles/cmTC_2dfa4.dir/testFortranCompiler.f-pp.f CMakeFiles/cmTC_2dfa4.dir/testFortranCompiler.f-pp.f.ddi
/usr/local/bin/flang -cpp -E testFortranCompiler.f -o CMakeFiles/cmTC_2dfa4.dir/testFortranCompiler.f-pp.f && /usr/local/bin/cmake -E cmake_ninja_depends --tdi=CMakeFiles/cmTC_2dfa4.dir/FortranDependInfo.json --pp=CMakeFiles/cmTC_2dfa4.dir/testFortranCompiler.f-pp.f --dep=CMakeFiles/cmTC_2dfa4.dir/testFortranCompiler.f-pp.f.d --obj=CMakeFiles/cmTC_2dfa4.dir/testFortranCompiler.f.o --ddi=CMakeFiles/cmTC_2dfa4.dir/testFortranCompiler.f-pp.f.ddi
# 1 "testFortranCompiler.f"
# 2 "testFortranCompiler.f"
PROGRAM TESTFortran
PRINT *, 'Hello'
END
CMake Error: -E cmake_ninja_depends failed to open CMakeFiles/cmTC_2dfa4.dir/testFortranCompiler.f-pp.f
ninja: build stopped: subcommand failed.
CMake will not be able to correctly generate this project.
Call Stack (most recent call first):
cmake/tribits/core/package_arch/TribitsGlobalMacros.cmake:1830 (ENABLE_LANGUAGE)
cmake/tribits/core/package_arch/TribitsProjectImpl.cmake:188 (TRIBITS_SETUP_ENV)
cmake/tribits/core/package_arch/TribitsProject.cmake:93 (TRIBITS_PROJECT_IMPL)
CMakeLists.txt:90 (TRIBITS_PROJECT)
```
but if I manually run the program and test it works
creating test program with the same contents of the above cmake command
```Fortran
PROGRAM TESTFortran
PRINT *, 'Hello'
END
```
save that as test.f
flang test.f
```shell
flang -v test.f
clang version 6.0.1
Target: x86_64-portbld-freebsd12.0
Thread model: posix
InstalledDir: /usr/local/flang/bin
"/usr/local/flang/bin/flang1" test.f -opt 0 -terse 1 -inform warn -nohpf -nostatic -inform warn -x 19 0x400000 -quad -x 68 0x1 -x 59 4 -x 15 2 -x 49 0x400004 -x 51 0x20 -x 57 0x4c -x 58 0x10000 -x 124 0x1000 -tp px -x 57 0xfb0000 -x 58 0x78031040 -x 47 0x08 -x 48 4608 -x 49 0x100 -def unix -def __unix -def __unix__ -def __FreeBSD__ -def __NO_MATH_INLINES -def __LP64__ -def __LONG_MAX__=9223372036854775807L -def __SIZE_TYPE__=unsigned long int -def __PTRDIFF_TYPE__=long int -def __x86_64 -def __x86_64__ -def __amd_64__amd64__ -def __k8 -def __k8__ -def __THROW= -def __extension__= -def __PGLLVM__ -nofreeform -idir /usr/local/include -idir /usr/local/flang/include -idir /usr/local/llvm60/include -idir /usr/local/llvm60/lib/clang/6.0.1/include -vect 48 -x 54 1 -x 70 0x40000000 -y 163 0xc0000000 -x 189 0x10 -stbfile test-2a5590.stb -modexport test-2a5590.cmod -modindex test-2a5590.cmdx -output test-2a5590.ilm
"/usr/local/flang/bin/flang2" test-2a5590.ilm -y 129 2 -ieee 0 -fn test.f -opt 0 -terse 1 -inform warn -inform warn -x 68 0x1 -x 51 0x20 -x 119 0xa10000 -x 122 0x40 -x 123 0x1000 -x 127 4 -x 127 17 -x 19 0x400000 -x 28 0x40000 -x 120 0x10000000 -x 70 0x8000 -x 122 1 -x 125 0x20000 -x 164 0x800000 -quad -x 59 4 -tp px -x 120 0x1000 -x 124 0x1400 -y 15 2 -x 57 0x3b0000 -x 58 0x48000000 -x 49 0x100 -astype 0 -x 183 4 -x 121 0x800 -x 54 0x10 -x 70 0x40000000 -x 249 50 -x 124 1 -y 163 0xc0000000 -x 189 0x10 -y 189 0x4000000 -x 183 0x10 -stbfile test-2a5590.stb -asm /tmp/test-2a5590.ll
"/usr/local/flang/bin/clang-6.0" -cc1 -triple x86_64-portbld-freebsd12.0 -emit-obj -mrelax-all -disable-free -main-file-name test.f -mrelocation-model static -mthread-model posix -mdisable-fp-elim -masm-verbose -mconstructor-aliases -munwind-tables -target-cpu x86-64 -dwarf-column-info -debugger-tuning=gdb -v -resource-dir /usr/local/flang/lib/clang/6.0.1 -Wno-unused-command-line-argument -fdebug-compilation-dir /wrkdirs/usr/ports/math/trilinos/work/.build -ferror-limit 19 -fmessage-length 294 -fobjc-runtime=gnustep -fdiagnostics-show-option -fcolor-diagnostics -o /tmp/test-02b4b5.o -x ir /tmp/test-2a5590.ll
clang -cc1 version 6.0.1 based upon LLVM 6.0.1 default target x86_64-portbld-freebsd12.0
"/usr/bin/ld" --eh-frame-hdr -dynamic-linker /libexec/ld-elf.so.1 --hash-style=both --enable-new-dtags -o a.out /usr/lib/crt1.o /usr/lib/crti.o /usr/lib/crtbegin.o -L/usr/local/lib -L/usr/local/flang/lib -L/usr/local/llvm60/lib -L/usr/lib -lflangmain -lm -lflang -lflangrti -lomptarget -lompstub -lomp -lpgmath -lm -lexecinfo /tmp/test-02b4b5.o -lgcc --as-needed -lgcc_s --no-as-needed -lc -lgcc --as-needed -lgcc_s --no-as-needed /usr/lib/crtend.o /usr/lib/crtn.o
```
running
```shell
./a.out
Hello
```
## Possible Solution
properly detect flang compiler?
## Your Environment
<!---
Include relevant details about your environment such that we can replicate this
issue.
-->
./configure -GNinja;
I already have the Kitware ninja fork that supports fortran.
## Additional Information
```shell
//Enable support for the TPL ExodusII in all supported Trilinos
// packages. This can be set to 'ON', 'OFF', or left empty ''.
Determining if the Fortran compiler works failed with the following output:
Change Dir: /wrkdirs/usr/ports/math/trilinos/work/.build/CMakeFiles/CMakeTmp
Run Build Command:"/usr/local/bin/ninja" "cmTC_6274f"
[1/4] Building Fortran preprocessed CMakeFiles/cmTC_6274f.dir/testFortranCompiler.f-pp.f
FAILED: CMakeFiles/cmTC_6274f.dir/testFortranCompiler.f-pp.f CMakeFiles/cmTC_6274f.dir/testFortranCompiler.f-pp.f.ddi
/usr/local/bin/flang -cpp -E testFortranCompiler.f -o CMakeFiles/cmTC_6274f.dir/testFortranCompiler.f-pp.f && /usr/local/bin/cmake -E cmake_ninja_depends --tdi=CMakeFiles/cmTC_6274f.dir/FortranDependInfo.json --pp=CMakeFiles/cmTC_6274f.dir/testFortranCompiler.f-pp.f --dep=CMakeFiles/cmTC_62
74f.dir/testFortranCompiler.f-pp.f.d --obj=CMakeFiles/cmTC_6274f.dir/testFortranCompiler.f.o --ddi=CMakeFiles/cmTC_6274f.dir/testFortranCompiler.f-pp.f.ddi
# 1 "testFortranCompiler.f"
# 2 "testFortranCompiler.f"
PROGRAM TESTFortran
PRINT *, 'Hello'
END
CMake Error: -E cmake_ninja_depends failed to open CMakeFiles/cmTC_6274f.dir/testFortranCompiler.f-pp.f
ninja: build stopped: subcommand failed.
Determining if the Fortran compiler works failed with the following output:
Change Dir: /wrkdirs/usr/ports/math/trilinos/work/.build/CMakeFiles/CMakeTmp
Run Build Command:"/usr/local/bin/ninja" "cmTC_2dfa4"
[1/4] Building Fortran preprocessed CMakeFiles/cmTC_2dfa4.dir/testFortranCompiler.f-pp.f
FAILED: CMakeFiles/cmTC_2dfa4.dir/testFortranCompiler.f-pp.f CMakeFiles/cmTC_2dfa4.dir/testFortranCompiler.f-pp.f.ddi
/usr/local/bin/flang -cpp -E testFortranCompiler.f -o CMakeFiles/cmTC_2dfa4.dir/testFortranCompiler.f-pp.f && /usr/local/bin/cmake -E cmake_ninja_depends --tdi=CMakeFiles/cmTC_2dfa4.dir/FortranDependInfo.json --pp=CMakeFiles/cmTC_2dfa4.dir/testFortranCompiler.f-pp.f --dep=CMakeFiles/cmTC_2d
fa4.dir/testFortranCompiler.f-pp.f.d --obj=CMakeFiles/cmTC_2dfa4.dir/testFortranCompiler.f.o --ddi=CMakeFiles/cmTC_2dfa4.dir/testFortranCompiler.f-pp.f.ddi
# 1 "testFortranCompiler.f"
# 2 "testFortranCompiler.f"
PROGRAM TESTFortran
PRINT *, 'Hello'
END
CMake Error: -E cmake_ninja_depends failed to open CMakeFiles/cmTC_2dfa4.dir/testFortranCompiler.f-pp.f
ninja: build stopped: subcommand failed.
```
https://gitlab.osti.gov/jmwille/Trilinos/-/issues/2264Four MueLu tests broken in CI build in push to MueLu on 2/19/20182018-03-30T14:43:23ZJames WillenbringFour MueLu tests broken in CI build in push to MueLu on 2/19/2018*Created by: bartlettroscoe*
**CC:** @trilinos/muelu, @trilinos/framework
## Next Action Status
The original failure was caused due to a violation of the [additive test assumption of branches](https://docs.google.com/document/d/1...*Created by: bartlettroscoe*
**CC:** @trilinos/muelu, @trilinos/framework
## Next Action Status
The original failure was caused due to a violation of the [additive test assumption of branches](https://docs.google.com/document/d/1uVQYI2cmNx09fDkHDA136yqDTqayhxqfvjFiuUue7wo/edit#bookmark=id.d1jneh8ubsyn) due to a 10 day time lag between when the branch was tested and when it was merged. See https://github.com/trilinos/Trilinos/pull/2171#issuecomment-367530716 and #2312.
## Description
The push of the merge commit:
```
commit 22e7f91ed633a22d6d44baf46d8f1e4fca7bfb3e
Merge: 52f3559 d851185
Author: Luc Berger <lberge@sandia.gov>
Date: Mon Feb 19 15:38:53 2018 -0700
Merge pull request #2171 from lucbv/develop
MueLu_structured_aggregation
```
broke the standard CI build as shown at:
* https://testing.sandia.gov/cdash/index.php?project=Trilinos&parentid=3395403&
which involved breaking the four tests:
* MueLu_UnitTestsEpetra_MPI_1
* MueLu_UnitTestsEpetra_MPI_4
* MueLu_UnitTestsTpetra_MPI_1
* MueLu_UnitTestsTpetra_MPI_4
This was the only merge commit pulled in the CI iteration as shown at:
* https://testing.sandia.gov/cdash/viewNotes.php?buildid=3395404##note3
Therefore, I will back out this merge commit and run the checkin-test-sems.sh script to fix this ASAP (but I will only run the MueLu test to speed this up). Since the CI build passed before this merge commit was pushed, that should be enough testing. Otherwise, everyone's automated PR testing for changes to MueLu or upsstream from MueLu will fail because of this.
https://gitlab.osti.gov/jmwille/Trilinos/-/issues/3440Framework: Add link to PR Test Replication to Autotester message2018-11-07T17:49:20ZJames WillenbringFramework: Add link to PR Test Replication to Autotester message*Created by: william76*
@trilinos/framework @allevin
It's come up that it would be tremendously helpful to the developer community if a link were provided to the wiki page: https://github.com/trilinos/Trilinos/wiki/Reproducing-PR-Te...*Created by: william76*
@trilinos/framework @allevin
It's come up that it would be tremendously helpful to the developer community if a link were provided to the wiki page: https://github.com/trilinos/Trilinos/wiki/Reproducing-PR-Testing-Errors in the test-result message the autotester kicks out.
I think a good place for this would be right after the `CDash Test Results for PR# NNNN.` link. Something like:
```
CDash Test Results for PR# NNNN.
Wiki: How to Reproduce PR Testing Builds and Errors
```
This would be especially useful to folks who are infrequent committers who might not be as familiar with navigation around the CDash system, etc.
https://gitlab.osti.gov/jmwille/Trilinos/-/issues/2594Framework: Allow commits to non-code directories w/o autotesting 2018-11-02T19:06:04ZJames WillenbringFramework: Allow commits to non-code directories w/o autotesting *Created by: csiefer2*
I'm thinking specifically of cmake/ctest/drivers, which contains stuff for driving nightly tests and not code that the autotester can actually execute.*Created by: csiefer2*
I'm thinking specifically of cmake/ctest/drivers, which contains stuff for driving nightly tests and not code that the autotester can actually execute.https://gitlab.osti.gov/jmwille/Trilinos/-/issues/2995Framework: Autotester may be busted?2018-06-21T13:54:55ZJames WillenbringFramework: Autotester may be busted?*Created by: csiefer2*
Been waiting 5 hours now for the testing to finish... See #2988
@trilinos/framework *Created by: csiefer2*
Been waiting 5 hours now for the testing to finish... See #2988
@trilinos/framework https://gitlab.osti.gov/jmwille/Trilinos/-/issues/5047Framework: Cannot push or pull from github2019-06-08T15:27:25ZJames WillenbringFramework: Cannot push or pull from github*Created by: csiefer2*
csiefer@mymachine> git pull --rebase
You don't exist, go away!
fatal: The remote end hung up unexpectedly
(It worked yesterday, FYI)*Created by: csiefer2*
csiefer@mymachine> git pull --rebase
You don't exist, go away!
fatal: The remote end hung up unexpectedly
(It worked yesterday, FYI)https://gitlab.osti.gov/jmwille/Trilinos/-/issues/2578Framework: Configure does not issue warning if package is both ON and OFF2018-04-18T17:06:19ZJames WillenbringFramework: Configure does not issue warning if package is both ON and OFF*Created by: csiefer2*
If you explicitly turn a package both ON and OFF during configure, cmake happily lets you do that without warning you that this might not be what you intended.
Can this be fixed in TriBITS / Trilinos?
@jwill...*Created by: csiefer2*
If you explicitly turn a package both ON and OFF during configure, cmake happily lets you do that without warning you that this might not be what you intended.
Can this be fixed in TriBITS / Trilinos?
@jwillenbring @bartlettroscoe https://gitlab.osti.gov/jmwille/Trilinos/-/issues/142Framework: Create GitHub tag for Thyra2016-02-15T17:56:10ZJames WillenbringFramework: Create GitHub tag for Thyra*Created by: mhoemmen*
Please :-) Issue #3 needs this.
*Created by: mhoemmen*
Please :-) Issue #3 needs this.
https://gitlab.osti.gov/jmwille/Trilinos/-/issues/3673Framework: Fix bug in PullRequestLinuxDriver for SERIAL builds2018-11-07T17:46:18ZJames WillenbringFramework: Fix bug in PullRequestLinuxDriver for SERIAL builds*Created by: william76*
@trilinos/framework
@jwillenbring
@prwolfe
the update to `PullRequestLinuxDriver.sh` script to wildcard "*_SERIAL" is wrong.
https://github.com/trilinos/Trilinos/blob/b64a5a4498abe7aedd1ffe42fb4795d...*Created by: william76*
@trilinos/framework
@jwillenbring
@prwolfe
the update to `PullRequestLinuxDriver.sh` script to wildcard "*_SERIAL" is wrong.
https://github.com/trilinos/Trilinos/blob/b64a5a4498abe7aedd1ffe42fb4795d756331615/cmake/std/PullRequestLinuxDriver.sh#L225-L229
This If/Else condition fails to correctly identify the _SERIAL piece, take this sample test code to illustrate:
```bash
#!/usr/bin/env bash
# uncomment one of these
JOB_BASE_NAME="Trilinos_pullrequest_gcc_4.9.3_SERIAL"
# JOB_BASE_NAME="Trilinos_pullrequest_gcc_4.9.3"
echo "JOB_BASE_NAME: $JOB_BASE_NAME"
echo "Test old method:"
if [ "*_SERIAL" != "${JOB_BASE_NAME:?}" ]; then
echo -e "- Job is MPI"
else
echo -e "- Job is SERIAL"
fi
echo "Test new method:"
regex=".*(_SERIAL)$"
if [[ ! ${JOB_BASE_NAME:?} =~ ${regex} ]]; then
echo -e "- Job name is MPI"
else
echo -e "- Job name is SERIAL"
fi
```
Run it with the non-serial version of `JOB_BASE_NAME` and you get:
```
$ ./test.sh
JOB_BASE_NAME: Trilinos_pullrequest_gcc_4.9.3
Test old method:
- Job is MPI
Test new method:
- Job name is MPI
```
Looks correct, right? Nope, it's just lucking into it via a bug. Run it with the `_SERIAL` job and you get this:
```
$ ./test.sh
JOB_BASE_NAME: Trilinos_pullrequest_gcc_4.9.3_SERIAL
Test old method:
- Job is MPI
Test new method:
- Job name is SERIAL
```
The method just comparing against "*_SERIAL" incorrectly thinks the string matches. I think this expression will always evaluate to `true` which is not what we want.
## TODO
- [x] Fix the script to use the new method described here to make that conditional operate properly.
https://gitlab.osti.gov/jmwille/Trilinos/-/issues/4069Framework: Intel Autotester is Woofing2018-12-20T15:56:10ZJames WillenbringFramework: Intel Autotester is Woofing*Created by: csiefer2*
Status Flag 'Pull Request AutoTester' - Failure: Timed out waiting for job Trilinos_pullrequest_intel_17.0.1 to start: Total Wait = 603
Other jobs have been previously started - We must stop them...
*Created by: csiefer2*
Status Flag 'Pull Request AutoTester' - Failure: Timed out waiting for job Trilinos_pullrequest_intel_17.0.1 to start: Total Wait = 603
Other jobs have been previously started - We must stop them...
https://gitlab.osti.gov/jmwille/Trilinos/-/issues/4809Framework: Non-framework machines no longer able to report to Cdash2019-04-09T23:16:48ZJames WillenbringFramework: Non-framework machines no longer able to report to Cdash*Created by: csiefer2*
And for that matter, the entire Nightly track is gone. SAD!
(Originally noticed by @lucbv)
@trilinos/framework
@trilinos/tpetra This will impact deprecation work after the release if it is not resolved...*Created by: csiefer2*
And for that matter, the entire Nightly track is gone. SAD!
(Originally noticed by @lucbv)
@trilinos/framework
@trilinos/tpetra This will impact deprecation work after the release if it is not resolved by then.https://gitlab.osti.gov/jmwille/Trilinos/-/issues/4424Framework: Parameterize CDash Tracks for Pull Request Tests2019-02-25T17:11:05ZJames WillenbringFramework: Parameterize CDash Tracks for Pull Request Tests*Created by: william76*
@trilinos/framework
We discussed parameterizing the PR testing drivers so we can specify in the Jenkins job which track we'd like the tests to go to.
I'm testing this [on my fork][1], but I added a parameter...*Created by: william76*
@trilinos/framework
We discussed parameterizing the PR testing drivers so we can specify in the Jenkins job which track we'd like the tests to go to.
I'm testing this [on my fork][1], but I added a parameter `PULLREQUEST_CDASH_TRACK` which, if set and non-empty will set the `CDASH_TRACK` variable that's used inside the `PullRequestLinuxDriver-Test.sh` script.
I'm running a quick test using my jenkins simulator and it looks like it's working as intended... using '0000' as the PR number, it's showing up in the Clean track [here][2].
### Tasks
- [x] Update `PullRequestLinuxDriver-Test.sh` to take in a parameter for the desired CDash track to report results to.
- [x] Add parameter `PULLREQUEST_CDASH_TRACK` to [Trilinos_pullrequest_cuda_9.2][3]
- [x] Add parameter `PULLREQUEST_CDASH_TRACK` to [Trilinos_pullrequest_gcc_4.8.4][4]
- [x] Add parameter `PULLREQUEST_CDASH_TRACK` to [Trilinos_pullrequest_gcc_4.9.3][5]
- [x] Add parameter `PULLREQUEST_CDASH_TRACK` to [Trilinos_pullrequest_gcc_4.9.3_SERIAL][6]
- [x] Add parameter `PULLREQUEST_CDASH_TRACK` to [Trilinos_pullrequest_gcc_7.2.0][7]
- [x] Add parameter `PULLREQUEST_CDASH_TRACK` to [Trilinos_pullrequest_gcc_7.3.0][8]
- [x] Add parameter `PULLREQUEST_CDASH_TRACK` to [Trilinos_pullrequest_intel_17.0.1][9]
- [x] Update PR Driver configuration in the autotester.
FYI: @jwillenbring
[1]: https://github.com/william76/Trilinos/blob/parameterized-pr-cdash-track/cmake/std/PullRequestLinuxDriver-Test.sh#L298-L312
[2]: https://testing-vm.sandia.gov/cdash/index.php?project=Trilinos&filtercombine=and&filtercombine=and&filtercombine=and&filtercombine=and&filtercombine=and&filtercombine=and&filtercombine=and&filtercount=2&showfilters=1&filtercombine=and&field1=buildname&compare1=63&value1=PR-0000-test&field2=buildstarttime&compare2=84&value2=NOW
[3]: https://ascic-jenkins.sandia.gov/job/trilinos-folder/job/Trilinos_pullrequest_cuda_9.2/
[4]: https://ascic-jenkins.sandia.gov/job/trilinos-folder/job/Trilinos_pullrequest_gcc_4.8.4/
[5]: https://ascic-jenkins.sandia.gov/job/trilinos-folder/job/Trilinos_pullrequest_gcc_4.9.3/
[6]: https://ascic-jenkins.sandia.gov/job/trilinos-folder/job/Trilinos_pullrequest_gcc_4.9.3_SERIAL/
[7]: https://ascic-jenkins.sandia.gov/job/trilinos-folder/job/Trilinos_pullrequest_gcc_7.2.0/
[8]: https://ascic-jenkins.sandia.gov/job/trilinos-folder/job/Trilinos_pullrequest_gcc_7.3.0/
[9]: https://ascic-jenkins.sandia.gov/job/trilinos-folder/job/Trilinos_pullrequest_intel_17.0.1/
https://gitlab.osti.gov/jmwille/Trilinos/-/issues/4034Framework: PR Tester GCC 7.2.0 Build Always Fails2018-12-18T22:26:12ZJames WillenbringFramework: PR Tester GCC 7.2.0 Build Always Fails*Created by: csiefer2*
And as a result all PRs are currently stuck in limbo.
For example:
https://github.com/trilinos/Trilinos/pull/4028
https://github.com/trilinos/Trilinos/pull/4027
https://github.com/trilinos/Trilinos/pull/40...*Created by: csiefer2*
And as a result all PRs are currently stuck in limbo.
For example:
https://github.com/trilinos/Trilinos/pull/4028
https://github.com/trilinos/Trilinos/pull/4027
https://github.com/trilinos/Trilinos/pull/4026
@trilinos/framework @jwillenbring @ZUUL42 @william76