Panzer: Clean up configure process

[bartlettroscoe]

When you try to configure Panzer under Trilinos, you must manually set several specialized options like:

  -D Intrepid_ENABLE_DEBUG_INF_CHECK:BOOL=OFF \
  -D IntrepidIntrepid2_ENABLE_DEBUG_INF_CHECK:BOOL=OFF \
  -D Teuchos_ENABLE_LONG_LONG_INT:BOOL=ON \
  -D TPL_ENABLE_Boost:BOOL=ON \
  -D TPL_ENABLE_BoostLib:BOOL=ON \
  -D TPL_ENABLE_Netcdf:BOOL=ON \

These things should be enabled automatically when Panzer gets enabled (either implicitly or explicitly). This will simplify a lot of configure scripts involving Panzer (such as with Drekar and downstream projects).

Tasks:

1. Set Intrepid2_ENABLE_DEBUG_INF_CHECK=OFF automatically when Panzer is enabled (either explicitly or implicitly) ... The default will be set to OFF unconditionally ...
2. Gather up disables for common Panzer/Drekar usage into a CMake fragment file for reuse ...
3. Set up automated build of Panzer (with Drekar disables) on hansen for non-CUDA build and post to CDash ...

CC: @rppawlo, @bathmatt, @eric-c-cyr

[rppawlo]

The debug inf checks are both incorrect. It should be one check that was recently changed to:

-D Intrepid2_ENABLE_DEBUG_INF_CHECK:BOOL=OFF \

The intrepid one was for the original library. Intrepid2 was then developed inside intrepid1 as a subpackage, so at some point we started using the IntrepidIntrepid2 flag. Now Intrepid2 was moved into its own package and so you should use this new one. I am going to disable the inf check in Intrepid2 by default so we don't need this flag anymore. I think it is only enabled for debug builds anyway.

We do need the teuchos long long flag, but IMHO this option should be removed all together. Trilinos requires c++11 and long long is now officially in the standard. The only reason it remains is that there are some applications that are still building portions of Trilinos without c++11. We need to get them changed over soon.

We removed all Boost and BoostLib dependencies from Phalanx and Panzer. However we still need this for panzer builds because panzer depends on STKClassic and STKClassic has a required dependence on BoostLib. Dumping STKClassic is realistically probably 6 months out depending on how other components progress.

We need netcdf long term.

[bartlettroscoe]

The debug inf checks are both incorrect. It should be one check that was recently changed to:

-D Intrepid2_ENABLE_DEBUG_INF_CHECK:BOOL=OFF \

The intrepid one was for the original library. Intrepid2 was then developed inside intrepid1 as a subpackage, so at some point we started using the IntrepidIntrepid2 flag. Now Intrepid2 was moved into its own package and so you should use this new one.

That is what is currently listed in the file README_BuildingTPLS.txt in Drekar. You might want to first update that file.

I am going to disable the inf check in Intrepid2 by default so we don't need this flag anymore. I think it is only enabled for debug builds anyway.

What is this check used for? How important is it? I think we can put in the logic to disable this when Panzer gets enabled automatically (along with a NOTE statement).

We do need the teuchos long long flag, but IMHO this option should be removed all together. Trilinos requires c++11 and long long is now officially in the standard. The only reason it remains is that there are some applications that are still building portions of Trilinos without c++11. We need to get them changed over soon.

Since Teuchos is still required to be buildable without C++11, we can't unconditionally change the default. However, we could change the default based on if C++11 is enabled or not. Should we ask the Trilinos developers about how they feel about enabling long long int by default if C++11 is enabled? Note that this will increase the number of default instantiations for Trilinos (because we can't currently disable the GO 'int', see #74).

We removed all Boost and BoostLib dependencies from Phalanx and Panzer. However we still need this for panzer builds because panzer depends on STKClassic and STKClassic has a required dependence on BoostLib. Dumping STKClassic is realistically probably 6 months out depending on how other components progress.

So we need BoostLib but not Boost now? There should just be one Boost TPL which can conditionally require various libs or not. That might be one thing I clean up too perhaps. Except we can't fix STK in Trilinos :-(

We need netcdf long term.

That is fine. It just means that Panzer should have a required dependency on Netcdf to trigger the enable of Netcdf when Panzer gets enabled. How the Netcdf libraries are found is another story (to be addressed).

The goal is that someone should be able to just do -DTrilinos_ENABLE_Panzer and everything should be handled automatically. The only thing we can smooth over automatically on all platforms is where the find the external TPLs (but we can do it on a few well defined platforms, see #158 and #172).

[rppawlo]

So we need BoostLib but not Boost now? There should just be one Boost TPL which can conditionally require various libs or not. That might be one thing I clean up too perhaps. Except we can't fix STK in Trilinos :-(

I think we still need both. Boost is 95% header-only libraries and some packages just want headers. bjam is a pain and to require packages to build libraries when it they need headers only is extra busy work. What we should probably do is rename "Boost" to "BoostHeadersOnly". That would make it explicit in what is expects.

That is fine. It just means that Panzer should have a required dependency on Netcdf to trigger the enable of Netcdf when Panzer gets enabled. How the Netcdf libraries are found is another story (to be addressed).

I don't understand this comment. Panzer has no direct dependencies on netcdf. It should not be declared in the Dependencies.cmake file for panzer. netcdf is an optional dependency of SEACAS ioss and is brought in in that dependency chain. The panzer adapters subpackage depends on seacas but still doesn't call anything directly. I thought our rule was to declare direct dependencies only. I think that in the future (if not already) IOSS will make netcdf optional (because we would use CGNS underneath) and in that case we won't need it.

[bartlettroscoe]

I think we still need both. Boost is 95% header-only libraries and some packages just want headers. bjam is a pain and to require packages to build libraries when it they need headers only is extra busy work. What we should probably do is rename "Boost" to "BoostHeadersOnly". That would make it explicit in what is expects.

We don't need two TPLs for Boost. The way it can work is that, by default, the Boost TPL will not require any libraries. But packages can request more Boost libraries by calling something like:

LIST(APPEND TPL_Boost_libs  boost_program_options)

and then when FindTPLBoost.cmake is processed, it will read ${TPL_Boost_libs}, entry by entry and then compare each item to a know list of possible boost libs. If an entry don't match, it will error out. If it does do match, it will add that Boost libs to look for (in the right order). Does that make sense? I think this should be less confusing for users and allow the list of boost libs to be extended in a cleaner way.

I thought our rule was to declare direct dependencies only

Yes, that is true in general, but by declaring a require dependency on Netcdf, you will trigger the right enable logic. That is a bit of a hack but it would do the trick. Actually, what you really want would be to somehow trigger SEACAS<SubPackage>_ENABLE_Netcdf=ON if Panzer was enabled. But that would take new logic in TriBITS. But as long Panzer's CMakeLists.txt file prints out a good error message if it detects that Netcdf is not enabled and then dies, that should be fine. You don't want to wait until build time to figure this out.

Any, we can work on this iteratively.

But I guess there are not that many customers for Panzer at this point. This is the type of issue that would be much easier if these customer codes just created a big meta-project that included Trilinos and then they can handle these types of issues automatically (like we do for CASL VERA).

[mhoemmen]

Should we ask the Trilinos developers about how they feel about enabling long long int by default if C++11 is enabled? Note that this will increase the number of default instantiations for Trilinos ...

Tpetra lets you disable any GO type in Tpetra explicitly, independently of Teuchos settings. For example, if you don't want GO=long long, set Tpetra_ENABLE_INT_LONG_LONG=OFF.

I would prefer to disable GO=int by default than GO=long long. See #74 etc.

[bartlettroscoe]

For example, if you don't want GO=long long, set Tpetra_ENABLE_INT_LONG_LONG=OFF.

Okay, good, I can see that long long int is enabled by default when C++11 is enabled looking in teuchos/CMakeLists.txt:

ASSERT_DEFINED(${PROJECT_NAME}_ENABLE_CXX11)
SET(${PACKAGE_NAME}_ENABLE_LONG_LONG_INT_DEFAULT ${${PROJECT_NAME}_ENABLE_CXX11})
TRIBITS_ADD_OPTION_AND_DEFINE(
  ${PACKAGE_NAME}_ENABLE_LONG_LONG_INT
  HAVE_TEUCHOS_LONG_LONG_INT
  "Enable Teuchos features for the 'long long' data type.  This is ON by default if and only if C++11 is enabled.  Please remember that 'long long' only entered the C++ language standard with C++11, even though many compilers supported it before."
  ${${PACKAGE_NAME}_ENABLE_LONG_LONG_INT_DEFAULT}
  )

Now we just need to be able to turn off GO=int (by default would be good when Epetra is not enabled). See comment in #74.

[bartlettroscoe]

Getting started with this, I wanted to see about how to simplify the configure script that Matt uses for his application (part of trying to reproduce his problem). I found that enabling all optional packages and then disabling the packages that you don't want (i.e. "black-listing") results in fewer enabled SE packages and less enable/disable variables one needed to set. We use blacklisting for CASL VERA and I have found it to be more robust than "white-listing" (i.e. not enabling optional packages and then manually enabling the packages you want).

I also ran into the issue of not setting Intrepid2_ENABLE_DEBUG_INF_CHECK=OFF and of the problem with enabling Pthreads (see #123). I added todos to have Intrepid2_ENABLE_DEBUG_INF_CHECK=OFF automatically set when Panzer is enabled and to gather up common disables for the customer's usage of Panzer (and Drekar).

---

Detailed Notes:

Looking at starting to clean up Panzer/Drekar configure scripts ...

Looking at the set of enabled packages from Matt's configure script for Drekar (which turns off optional packages then turns many packages on and off) for Drekar, the package enables/disables look like:

./do-configure [other stuff] \
-D Trilinos_EXTRA_REPOSITORIES="DrekarResearch,DrekarBase" \
-D Trilinos_ENABLE_KokkosCore:BOOL=ON \
-D Trilinos_ENABLE_KokkosAlgorithms:BOOL=ON \
-D Trilinos_ENABLE_ALL_PACKAGES:BOOL=OFF \
-D Trilinos_ENABLE_ALL_OPTIONAL_PACKAGES:BOOL=OFF \
-D Trilinos_ENABLE_Teko:BOOL=ON \
-D Trilinos_ENABLE_Belos:BOOL=ON \
-D Trilinos_ENABLE_Panzer:BOOL=ON \
-D Trilinos_ENABLE_Shards:BOOL=ON \
-D Trilinos_ENABLE_Stratimikos:BOOL=ON \
-D Trilinos_ENABLE_ML:BOOL=ON \
-D Trilinos_ENABLE_Zoltan:BOOL=ON \
-D Trilinos_ENABLE_FEI:BOOL=ON \
-D Trilinos_ENABLE_Amesos:BOOL=ON \
-D Trilinos_ENABLE_SEACAS:BOOL=ON \
-D Trilinos_ENABLE_SEACASIoss:BOOL=ON \
-D Trilinos_ENABLE_STK:BOOL=ON \
-D Trilinos_ENABLE_STKClassic:BOOL=ON \
-D Trilinos_ENABLE_STKMesh:BOOL=OFF \
-D Trilinos_ENABLE_STKUtil:BOOL=OFF \
-D Trilinos_ENABLE_STKSearch:BOOL=OFF \
-D Trilinos_ENABLE_STKTopology:BOOL=OFF \
-D Trilinos_ENABLE_STKTransfer:BOOL=OFF \
-D Trilinos_ENABLE_STKDoc_tests:BOOL=OFF \
-D Trilinos_ENABLE_STKUnit_tests:BOOL=OFF \
-D Trilinos_ENABLE_STKUnit_test_utils:BOOL=OFF \
-D Trilinos_ENABLE_Stokhos:BOOL=OFF \
-D Trilinos_ENABLE_Drekar:BOOL=ON \
-D Trilinos_ENABLE_DrekarMHD:BOOL=ON

Running this configure script produced the following set of enabled packages and SE packages:

• Final set of enabled packages: Gtest Kokkos Teuchos RTOp Sacado Epetra Zoltan Shards Triutils Tpetra EpetraExt Thyra AztecOO Galeri Amesos Pamgen Ifpack ML Belos SEACAS Anasazi Ifpack2 Stratimikos FEI Teko Intrepid2 STK Phalanx NOX Rythmos Piro Panzer DrekarMHD Drekar 34
• Final set of enabled SE packages: Gtest KokkosCore KokkosContainers KokkosAlgorithms Kokkos TeuchosCore TeuchosParameterList TeuchosComm TeuchosNumerics TeuchosRemainder TeuchosKokkosCompat TeuchosKokkosComm Teuchos RTOp Sacado Epetra Zoltan Shards Triutils TpetraClassic TpetraKernels TpetraCore Tpetra EpetraExt ThyraCore ThyraEpetraAdapters ThyraEpetraExtAdapters ThyraTpetraAdapters Thyra AztecOO Galeri Amesos Pamgen Ifpack ML Belos SEACASExodus SEACASExodus_for SEACASNemesis SEACASIoss SEACASChaco SEACASAprepro_lib SEACASSupes SEACASSuplib SEACASSuplibCpp SEACASAlgebra SEACASAprepro-orig SEACASAprepro SEACASConjoin SEACASEjoin SEACASEpu SEACASExodiff SEACASExomatlab SEACASExotxt SEACASExo_format SEACASEx1ex2v2 SEACASGjoin SEACASGen3D SEACASGenshell SEACASGrepos SEACASGrope SEACASMapvarlib SEACASMapvar SEACASMapvar-kd SEACASNemslice SEACASNemspread SEACASNumbers SEACASTxtexo SEACASEx2ex1v2 SEACAS Anasazi Ifpack2 Stratimikos FEI Teko Intrepid2 STKClassic STK Phalanx NOX Rythmos Piro PanzerCore PanzerDofMgr PanzerDiscFE PanzerAdaptersSTK Panzer DrekarMHD Drekar 89

I want to look into enabling optional packages and then back-listing packages that you don't want. I came up with this configure list:

$ ./do-configure \
  -DTrilinos_EXTRA_REPOSITORIES=DrekarResearch,DrekarBase \
  -DTrilinos_ENABLE_Drekar=ON \
  -DTrilinos_ENABLE_DrekarMHD=ON \
  -DTrilinos_ENABLE_ThreadPool=OFF \
  -DTrilinos_ENABLE_TpetraTSQR=OFF \
  -DTrilinos_ENABLE_GlobiPack=OFF \
  -DTrilinos_ENABLE_Xpetra=OFF \
  -DTrilinos_ENABLE_OptiPack=OFF \
  -DTrilinos_ENABLE_Isorropia=OFF \
  -DTrilinos_ENABLE_Zoltan2=OFF \
  -DTrilinos_ENABLE_Amesos2=OFF \
  -DTrilinos_ENABLE_Intrepid=OFF \
  -DTrilinos_ENABLE_MueLu=OFF \
  -DTrilinos_ENABLE_MOOCHO=OFF \
  -DTrilinos_ENABLE_Stokhos=OFF \
  -DTrilinos_ENABLE_ROL=OFF

After fixing DrekarResearch/drekar_mhd/cmake/Dependencies.cmake to depend on STKClassic instead of STK, I ran this configure script and it yielded the following set of enabled packages and SE packages:

• Final set of enabled packages: Gtest Kokkos Teuchos RTOp Sacado Epetra Zoltan Shards Triutils Tpetra EpetraExt Thyra AztecOO Galeri Amesos Pamgen Ifpack ML Belos SEACAS Anasazi Ifpack2 Stratimikos FEI Teko Intrepid2 STK Phalanx NOX Rythmos Piro Panzer DrekarMHD Drekar 34
• Final set of enabled SE packages: Gtest KokkosCore KokkosContainers KokkosAlgorithms Kokkos TeuchosCore TeuchosParameterList TeuchosComm TeuchosNumerics TeuchosRemainder TeuchosKokkosCompat TeuchosKokkosComm Teuchos RTOp Sacado Epetra Zoltan Shards Triutils TpetraClassic TpetraKernels TpetraCore Tpetra EpetraExt ThyraCore ThyraEpetraAdapters ThyraEpetraExtAdapters ThyraTpetraAdapters Thyra AztecOO Galeri Amesos Pamgen Ifpack ML Belos SEACASExodus SEACASExodus_for SEACASNemesis SEACASIoss SEACASChaco SEACASSupes SEACASSuplib SEACASSuplibCpp SEACASEpu SEACASExodiff SEACASNemslice SEACASNemspread SEACAS Anasazi Ifpack2 Stratimikos FEI Teko Intrepid2 STKClassic STK Phalanx NOX Rythmos Piro PanzerCore PanzerDofMgr PanzerDiscFE PanzerAdaptersSTK Panzer DrekarMHD Drekar 68

As you can see, the approach of enabling all optional packages and then black-listing required only 15 enables/disables compared to 28 enables/disables and gave only 68 enabled SE packages compared to 89 enabled SE packages compared to the appraoch of turning off optional eanbles and then doing many enables and disables. But does it build? It should if the dependencies stated in the Dependencies.cmake file are correct. That will need to be tested to be sure (and the fix the missing dependencies).

I will now just configure and build Panzer to try to reproduce Matt's build errors. Does Drekar depend on more packages that Panzer?

$ time ./do-configure \
  -DTrilinos_ENABLE_Panzer=ON \
  -DTrilinos_ENABLE_ThreadPool=OFF \
  -DTrilinos_ENABLE_TpetraTSQR=OFF \
  -DTrilinos_ENABLE_GlobiPack=OFF \
  -DTrilinos_ENABLE_Xpetra=OFF \
  -DTrilinos_ENABLE_OptiPack=OFF \
  -DTrilinos_ENABLE_Isorropia=OFF \
  -DTrilinos_ENABLE_Zoltan2=OFF \
  -DTrilinos_ENABLE_Amesos2=OFF \
  -DTrilinos_ENABLE_Intrepid=OFF \
  -DTrilinos_ENABLE_MueLu=OFF \
  -DTrilinos_ENABLE_MOOCHO=OFF \
  -DTrilinos_ENABLE_Stokhos=OFF \
  -DTrilinos_ENABLE_ROL=OFF \
  -DTPL_ENABLE_Pthread=OFF \
  -DIntrepid2_ENABLE_DEBUG_INF_CHECK=OFF \
  &> configure.out

real    1m17.972s
user    0m58.054s
sys     0m7.803s

(NOTE: you get strange test failures unless you set -DIntrepid2_ENABLE_DEBUG_INF_CHECK=OFF and you get inconsistent node types between Tpetra and Kokkos which results in a bunch of runtime failures unless you set -DTPL_ENABLE_Pthread=OFF. TODO: Have Intrepid2_ENABLE_DEBUG_INF_CHECK=OFF set by defualt when Panzer is enabled.)

With just Panzer enabled, I get the same parent packages as for enabling Drekar but several fewer SE packages:

• Final set of enabled packages: Gtest Kokkos Teuchos RTOp Sacado Epetra Zoltan Shards Triutils Tpetra EpetraExt Thyra AztecOO Galeri Amesos Pamgen Ifpack ML Belos SEACAS Anasazi Ifpack2 Stratimikos FEI Teko Intrepid2 STK Phalanx NOX Rythmos Piro Panzer 32
• Final set of enabled SE packages: Gtest KokkosCore KokkosContainers KokkosAlgorithms Kokkos TeuchosCore TeuchosParameterList TeuchosComm TeuchosNumerics TeuchosRemainder TeuchosKokkosCompat TeuchosKokkosComm Teuchos RTOp Sacado Epetra Zoltan Shards Triutils TpetraClassic TpetraKernels TpetraCore Tpetra EpetraExt ThyraCore ThyraEpetraAdapters ThyraEpetraExtAdapters ThyraTpetraAdapters Thyra AztecOO Galeri Amesos Pamgen Ifpack ML Belos SEACASExodus SEACASIoss SEACAS Anasazi Ifpack2 Stratimikos FEI Teko Intrepid2 STKClassic STK Phalanx NOX Rythmos Piro PanzerCore PanzerDofMgr PanzerDiscFE PanzerAdaptersSTK Panzer 56

It looks like Drekar is enabling several SEACAS subpackages that Panzer is not. But that is the only difference that I can see.

What I would do is to put these package disables into a CMake fragment file so that they could be reused. I would call it something like PanzerDisables.cmake and then they could be passed through in Trilinos_CONFIGURE_OPTIONS_FILE in a do-configure script.

Building and running Panzer tests:

$ time make -j32 &> make.out  # Was a rebuild after adding few disables ...

real    10m12.804s
user    105m59.145s
sys     76m15.376s

$ time ctest -j32 &> ctest.out

real    2m11.883s
user    35m13.549s
sys     1m37.950s

This gave all passing tests:

100% tests passed, 0 tests failed out of 110

Label Time Summary:
Panzer    = 405.49 sec (110 tests)

Total Test time (real) = 131.87 sec

But this just creates a SERIAL node, not CUDA. Matt is having trouble with nvcc_wrapper.

[bartlettroscoe]

Once we get the Panzer configure cleaned up, then should set up nightly builds on the ATTB machines (using ATTBDevEnv.cmake) and post results to the Trilinos CDash site. This will be a way of ensuring the ATTBDenvEnv.cmake module #172 works with Trilinos on this machine. This will catch changes in the dev env on the ATTB machines or changes to Trilinos that brake this basic build.

[bartlettroscoe]

It just occurred to me that I don't need to wait until I have the configures totally cleaned up before I add automated testing. Therefore, next I will set up a cron job to do the Panzer configure, build, and test mentioned above to make sure this keeps working. If someone on the SEMS team wants to replace this cron job with a Jenkins driver, that is fine with me.

But all I have working right now is the non-CUDA build on hansen and shiller. The CUDA build will likely take some more time.

[bartlettroscoe]

In the below email thread, the decision was made to just unconditionally set the default for Intrepid2_ENABLE_DEBUG_INF to OFF. Therefore, we will not have to implement a TriBITS feature that allows the Panzer package to turn off Intrepid2_ENABLE_DEBUG_INF.

The long-term solution of changing Panzer to use subviews will go into another story issue for Panzer.

---

From: Bartlett, Roscoe A
Sent: Wednesday, April 06, 2016 1:42 PM
To: Pawlowski, Roger P; Perego, Mauro (-EXP); Cyr, Eric C; Kim, Kyungjoo (-EXP)
Cc: Bettencourt, Matthew
Subject: RE: Change defaults in intrepid2

Roger,

It would be a feature that would hopefully only rarely be used and would be
easy to abuse. It makes the relationship between packages more complex. But
as you said, the biggest drawback is the work to implement and unit test it
(likely 3 hours of work or so). But then this feature may solve some problems
that are currently more complex/difficult (or impossible) to solve in other
ways. But there is a huge list of potential features like this for TriBITS:

https://docs.google.com/document/d/1WKs8rJhI3037yKGnEVMhIx9dPN7a7uFRM5isdNAhAXI

I just did not want people to think this new TriBITS feature would take a lot
of runtime (because it likely would not).

Short term: Set the default for Intrepid2_ENABLE_DEBUG_INF to OFF
(unconditionally)

Long term: Change to use array subviews to avoid touching memory that is not
initialized.

Sounds good to me.

Cheers,

-Ross

---

From: Pawlowski, Roger P
Sent: Wednesday, April 06, 2016 1:34 PM
To: Bartlett, Roscoe A; Perego, Mauro (-EXP); Cyr, Eric C; Kim,
Kyungjoo (-EXP)
Cc: Bettencourt, Matthew
Subject: Re: Change defaults in intrepid2

ok. In addition to the runtime overhead, I was thinking that it seemed
like alot of work in tribits to add and do testing when we do have a
simple work around. If this is a capability you would like long term
in tribits, then we should definitely add it. But if it is only being
done for this panzer issue, then we can avoid adding extra complexity to
tribits.

Roger

---

From: Bartlett, Roscoe A
Sent: Wednesday, April 6, 2016 1:29 PM
To: Pawlowski, Roger P; Perego, Mauro (-EXP); Cyr, Eric C; Kim,
Kyungjoo (-EXP)
Cc: Bettencourt, Matthew
Subject: RE: Change defaults in intrepid2

Roger,

This solution is obiously fine with me. But note that given the incresed
speed of CMake 3.3.2, I would not worry about increased configure time. My
guess is that this would only add about 0.01s to the configure time.

-Ross

---

From: Pawlowski, Roger P
Sent: Wednesday, April 06, 2016 1:24 PM
To: Perego, Mauro (-EXP); Cyr, Eric C; Kim, Kyungjoo (-EXP)
Cc: Bettencourt, Matthew; Bartlett, Roscoe A
Subject: Re: Change defaults in intrepid2

Hi All,

The fastest fix with least hassle is to change:

TRIBITS_ADD_OPTION_AND_DEFINE(${PACKAGE_NAME}_ENABLE_DEBUG_INF
_CHECK
     HAVE_INTREPID2_DEBUG_INF_CHECK
     "Enable a host of runtime debug checking for infs and nans."
     ${${PROJECT_NAME}_ENABLE_DEBUG})

to:

TRIBITS_ADD_OPTION_AND_DEFINE(${PACKAGE_NAME}_ENABLE_DEBUG_INF
_CHECK
     HAVE_INTREPID2_DEBUG_INF_CHECK
     "Enable a host of runtime debug checking for infs and nans."
     OFF)

So no flags need be specified by default for panzer builds. Then in
panzer I will put a configure check that errors out if someone
enabled the inf checking. Then we won;t need to slow down configures
with an extra package traversal in tribits, panzer will build by
default without a special configure flag and panzer is protected if
someone enables inf
checking.

Roger

[github-actions]

This issue has had no activity for 365 days and is marked for closure. It will be closed after an additional 30 days of inactivity.
If you would like to keep this issue open please add a comment and remove the MARKED_FOR_CLOSURE label.
If this issue should be kept open even with no activity beyond the time limits you can add the label DO_NOT_AUTOCLOSE.

[github-actions]

This issue was closed due to inactivity for 395 days.