Futility issueshttps://code.ornl.gov/groups/futility/-/issues2021-07-14T14:59:31Zhttps://code.ornl.gov/futility/Futility/-/issues/321CI Improvements2021-07-14T14:59:31ZGraham, Aarongrahamam@ornl.govCI ImprovementsThe following discussion from !338 should be addressed:
- [ ] @ag6 started a [discussion](https://code.ornl.gov/futility/Futility/-/merge_requests/338#note_593855):
> What's there looks pretty good to me, aside from the couple thi...The following discussion from !338 should be addressed:
- [ ] @ag6 started a [discussion](https://code.ornl.gov/futility/Futility/-/merge_requests/338#note_593855):
> What's there looks pretty good to me, aside from the couple things that are obviously for debugging purposes. A couple things that would be good to add (which I'm guessing you probably thought of already:
>
> * [ ] find the right compiler/environment
> * [ ] debug build
> * [ ] unused variables/parameters check (like in MPACT)
> * [ ] spurious WRITE statement check (also like in MPACT)
> * [ ] travis-ci had a Trilinos build... we should decide if we want that or nothttps://code.ornl.gov/futility/Futility/-/issues/312Use new ASSERT_* macros in testParameterLists2021-03-05T15:22:04ZCOLLINSBS emailUse new ASSERT_* macros in testParameterLists*Created by: aarograh*
There is an argument for making these all `ASSERT_EQ`.
_Originally posted by @HendersonSC in https://github.com/CASL/Futility/pull/311#discussion_r588355883_*Created by: aarograh*
There is an argument for making these all `ASSERT_EQ`.
_Originally posted by @HendersonSC in https://github.com/CASL/Futility/pull/311#discussion_r588355883_https://code.ornl.gov/futility/Futility/-/issues/303Geom_Graph needs additional doxygen comments filled in2021-02-01T13:47:51ZCOLLINSBS emailGeom_Graph needs additional doxygen comments filled in*Created by: aarograh*
Looks like you got a lot of Doxygen added but some is still missing.
_Originally posted by @HendersonSC in https://github.com/CASL/Futility/pull/302#discussion_r566437589_*Created by: aarograh*
Looks like you got a lot of Doxygen added but some is still missing.
_Originally posted by @HendersonSC in https://github.com/CASL/Futility/pull/302#discussion_r566437589_https://code.ornl.gov/futility/Futility/-/issues/272Improve implicit solve in BDF ode stepper2020-07-20T23:17:59ZCOLLINSBS emailImprove implicit solve in BDF ode stepper*Created by: wgurecky*
The current BDF stepper only updates the jacobian once every 20 steps:
https://github.com/CASL/Futility/blob/9dc98226cf1cf6d3c3e2d1355f7f7a3bb696ba04/src/ODESolverTypes.f90#L638
This is not adequate for some v...*Created by: wgurecky*
The current BDF stepper only updates the jacobian once every 20 steps:
https://github.com/CASL/Futility/blob/9dc98226cf1cf6d3c3e2d1355f7f7a3bb696ba04/src/ODESolverTypes.f90#L638
This is not adequate for some very stiff problems. it is in this situation where one would apply the BDF family of methods over explicit marching methods. This could also be seen as a deficiency in the current implementation because a user of the BDF stepper will expect the algorithm to handle stiff systems without issue.
The proposed enhancement is to update the jacobian via the approximate Broyden's method after each nonlinear iteration is performed in the implicit solve. This approximate method is recommended since the expense of updating the jacobian via finite difference precludes this from being viable when embedded in the innermost nonlinear iteration loop.
This should improve overall roubustness of the BDF ode stepper.https://code.ornl.gov/futility/Futility/-/issues/257Missing interfaces to BLAS routines for some VectorTypes + argument rearrange...2020-06-03T03:54:31ZCOLLINSBS emailMissing interfaces to BLAS routines for some VectorTypes + argument rearrangement.*Created by: jpjones6*
The following vector types are missing interfaces to the listed BLAS routines:
- TrilinosVectorType:
- Dot (dot product)
- axpy_vector (component wise y=a*x+y)
- iamax (absolute max index find)
...*Created by: jpjones6*
The following vector types are missing interfaces to the listed BLAS routines:
- TrilinosVectorType:
- Dot (dot product)
- axpy_vector (component wise y=a*x+y)
- iamax (absolute max index find)
- iamin (absolute min index find)
- swap (x -> y , y -> x)
- NativeDistributedVectorType
- asum (absolute sum)
- iamax (absolute max index find)
- iamin (absolute min index find)
- scal_scalar (y=a*y)
- scal_vector (component wise y=a*y)
- swap (x -> y , y -> x)
Some of these have direct equivalents in their respective packages, however, I see no reason why these interfaces couldn't be directed to those allowing them to be fully general.
Additionally a number of the existing interfaces have their arguments out of order in comparison to their BLAS routine counterparts. For instance the vector interface for axpy (normally (a, x, y)) is in the order (x, y, a)...literally doesn't match the name of the interface. This is a needless difference.https://code.ornl.gov/futility/Futility/-/issues/256Do not automatically recursively search PL when full path is provided2020-09-22T14:16:15ZCOLLINSBS emailDo not automatically recursively search PL when full path is provided*Created by: aarograh*
There have been instances of the wrong parameter being fetched when a full path was provided to the correct parameter, specifically due to the fact that the `has` method returned true when it should not have. Thi...*Created by: aarograh*
There have been instances of the wrong parameter being fetched when a full path was provided to the correct parameter, specifically due to the fact that the `has` method returned true when it should not have. This issue covers efforts to address this.
Two changes are suggested:
1. Add an optional `recursive` argument to `has` and `get` functions. If set to true, then the current recursive search will be performed. Otherwise, only the exactly specified path will be searched
2. Modify the `has` and `get` functions to use this recursive argument. By default, if at least one `->` is present in the parameter name, a recursive search should NOT be done. If a single parameter name is provided with no path (i.e., no `->`), then a recursive search will occur by default. However, the optional argument will be exposed for the client code to override these default behaviors in either case.
This will eliminate some unpredictable behavior that has been problematic for client-side code. Additionally, it is expected that eliminating the recursive searches could have non-trivial performance improvements as well.https://code.ornl.gov/futility/Futility/-/issues/252Remove deprecated enumerations in EigenvalueSolverTypes and LinearSolverTypes2020-05-27T19:38:33ZCOLLINSBS emailRemove deprecated enumerations in EigenvalueSolverTypes and LinearSolverTypes*Created by: aarograh*
Follow-on work from #231 , :
- [ ] Change MPACT to use the new `EV_*` and `LINSYS_*` enumerations
- [ ] Remove the old versions of said enumerations in Futility*Created by: aarograh*
Follow-on work from #231 , :
- [ ] Change MPACT to use the new `EV_*` and `LINSYS_*` enumerations
- [ ] Remove the old versions of said enumerations in Futilityhttps://code.ornl.gov/futility/Futility/-/issues/241Futility doesn't build with PETSC enabled and MPI disabled2020-03-30T14:39:01ZCOLLINSBS emailFutility doesn't build with PETSC enabled and MPI disabled*Created by: tghaddar*
I tried to build Futility (as part of MPACT) with PETSC enabled and MPI disabled, and ended up with an " mpi.h: No such file or directory" error message. *Created by: tghaddar*
I tried to build Futility (as part of MPACT) with PETSC enabled and MPI disabled, and ended up with an " mpi.h: No such file or directory" error message. https://code.ornl.gov/futility/Futility/-/issues/215Extend ExceptionHandler to allow user defined exceptions and exception tagging2020-01-02T20:26:28ZCOLLINSBS emailExtend ExceptionHandler to allow user defined exceptions and exception tagging*Created by: wgurecky*
This is a proposed enhancement of ExceptionHandler to allow the registration of user defined exception types derived from a base exception type.
Benefits
---
- Usability: allow client code to handle an unl...*Created by: wgurecky*
This is a proposed enhancement of ExceptionHandler to allow the registration of user defined exception types derived from a base exception type.
Benefits
---
- Usability: allow client code to handle an unlimited variety of exceptions _without_ having to interrogate the log file or look at the lastMesg string.
- Code organization: place logic regarding error message generation into the user exception type.
# Proposed Design
## Module ExceptionHandler
### ExceptionHandlerType
#### Attributes
- Remove: `nError, nWarning`, ect. `verbose`, `quiet`
- New: exceptionRegistry - contains user defined exceptions.
- New: isInit - bool flag
#### Methods
- New method: init() - Fill the exceptionRegistry with the 5 default exception types.
- New method: registerException(e,userExcept) - enforce unique tags
- New method: raise(e,userExcept,msg) or raise(e,tag,msg)
- New method: getErrorCountByType(e,userExcept) or getErrorCountByTag(e,tag)
- Remove: logMessage
- Remove: exceptionStop
- Redef: raiseError, raiseWarning, ect become aliases to the more general `raise` method.
##### Notes:
- Enforce that init() is called before using the exception handler.
- Keep all existing functionality for legacy support. All existing ExceptionHandler tests should pass.
- __Unresolved__: how to safely copy from surrogate and defer raises to surrogate.
## Module ExceptionType
### ExceptionTypeBase
#### Attributes
- tag - integer, unique id of exception type
- counter - integer
- quiet - bool flag
- verbose - bool flag
- stopmode - bool flag
#### Methods
- init(tag)
- onRaise(isQuiet, isLogActive,logUnit,mesg)
- getCount, setCount, getQuiet, setQuiet, getVerbose, setVerbose
- logMessage(isQuiet, isLogActive,logUnit,mesg)
#### Virtual
- genPrefix
#### Module (non Type-bound)
- exceptionStop(stopmode)
### ExceptionTypeError,extends(ExceptionTypeBase)
- genPrefix() -> "#### EXCEPTION_ERROR ####"
https://code.ornl.gov/futility/Futility/-/issues/188Direct call to MPI_Abort leads to cryptic error message2019-08-21T14:54:15ZCOLLINSBS emailDirect call to MPI_Abort leads to cryptic error message*Created by: rks171*
A test I wrote was not calling MPI_Init. There was a mistake in the parameter list for setting up the MatrixType. When the exception handler was called, it was erroring on the MPI_Abort call found here https://git...*Created by: rks171*
A test I wrote was not calling MPI_Init. There was a mistake in the parameter list for setting up the MatrixType. When the exception handler was called, it was erroring on the MPI_Abort call found here https://github.com/CASL/Futility/blob/f0470bf365f1832e9ee87831149d4cd5b8a1b214/src/ExceptionHandler.f90#L1052. This presents a cryptic error message, `system msg for write_line failure : Bad file descriptor` instead of the useful one in the error handler. This section of the code should be checking if mpi was actually initialized, possible by calling the ParallelEnv object that is relevant instead.https://code.ornl.gov/futility/Futility/-/issues/167UnitTest FINALIZE_TEST will deadlock for some MPI tests2019-02-19T22:28:57ZCOLLINSBS emailUnitTest FINALIZE_TEST will deadlock for some MPI tests*Created by: rks171*
If using multiple processors and ASSERT is not called on all procs at least once, FINALIZE_TEST will deadlock because the processors where ASSERT was not called will not enter this if block:
```
236 IF(t...*Created by: rks171*
If using multiple processors and ASSERT is not called on all procs at least once, FINALIZE_TEST will deadlock because the processors where ASSERT was not called will not enter this if block:
```
236 IF(tmp%npass+tmp%nfail>0) THEN
```
Root will post a MPI_Recv that will never get sent. The workaround is to just call ASSERT(.true., "") on any procs where no ASSERT is otherwise called.https://code.ornl.gov/futility/Futility/-/issues/66Enable Trilinos/TeuchosWrappersExt as a TPL2017-11-09T23:49:43ZCOLLINSBS emailEnable Trilinos/TeuchosWrappersExt as a TPL*Created by: bscollin*
In order to reduce build times, specifically in the CI, it is desirable to use a prebuilt version of Trilinos and TeuchosWrappersExt instead of building the packages. @bartlettroscoe has introduced a small patch...*Created by: bscollin*
In order to reduce build times, specifically in the CI, it is desirable to use a prebuilt version of Trilinos and TeuchosWrappersExt instead of building the packages. @bartlettroscoe has introduced a small patch to TriBITS which allows projects to switch between building the package and using the prebuilt version. This issue is to track the implementation of this feature.
**Definition of Done**
Prototype of using Trillinos and TeuchosWrappersExt as prebuilt libraries is completedhttps://code.ornl.gov/futility/Futility/-/issues/39Optimize BLAS interfaces for VectorTypes2017-07-17T20:02:54ZCOLLINSBS emailOptimize BLAS interfaces for VectorTypes*Created by: youngmit*
The current implementations of the BLAS interfaces for the vector types are quite inefficient, and make heavy use of SELECT TYPE where unnecessary. The main concern is that almost all of the native implementations...*Created by: youngmit*
The current implementations of the BLAS interfaces for the vector types are quite inefficient, and make heavy use of SELECT TYPE where unnecessary. The main concern is that almost all of the native implementations make a copy of the vector data before operating on it, instead of doing so in-place. Some, but not all of the TPL-backed implementations do the same.