Corbett/kernel specs #3273
Corbett/kernel specs #3273
Conversation
…for kernel dispatch. Builds and runs (solid mechanics and poromechanics) with minimal kernel spec.
| "( "<<( ( "\n " + LvArray::system::demangle( internal::typeIdWrapper( objects ).name() ) ) + ... )<<" \n)\n" | ||
| // << | ||
| // "and the dispatch options are:\n"<< | ||
| // internal::listToString( combinations, "\n(", "\n)", typeListPrinter ) |
There was a problem hiding this comment.
Because combinations has so many different types I have run into compiler bugs when trying to print it out. Luckily the stack trace here seems to work find and that contains the types.
| // using SUBREGION_TYPES = types::Slice< DISPATCH_TYPE_LIST >; | ||
| using SUBREGION_TYPES = types::TypeList< CellElementSubRegion >; |
There was a problem hiding this comment.
This is a hack, but I am not sure how we want to do this. The types::Slice that I commented out will return a list of the first element from the list-of-lists DISPATCH_TYPE_LIST, but for what we have now this is just a list containing many copies of CellElementSubRegion. So many copies in fact that NVCC gives up in forElementSubRegions.
| @@ -0,0 +1,512 @@ | |||
| { | |||
There was a problem hiding this comment.
@rrsettgast do we need all these combinations?
|
@rrsettgast @wrtobin I think you guys should give this a look over. I commented a few of the pain points. It passes most of the integrated tests on ruby (except a few FPE runtime errors and restart checks I think are unrelated to this PR) and I have been unable to run them on Lassen. All in all the compilation is still extremely slow. It takes almost two hours to compile on Lassen, most of which is spent linking. |
TODO: If the
jsonfile is modified CMake doesn't run again.Not a fan of having to duplicate the function declarations again in the
.cpp.templatefile. Many of the functions have very complicated declarations and the errors obtained from mistakes are sure to cause headaches. For me this was inphysicsSolvers/fluidFlow/CompositionalMultiphaseHybridFVMKernels_impl.hpp. One alternative is to define explicit instantiation macros in this header so at least you don't have to update two different files. You'd still have to list out the function arguments twice unless we resorted to some more intrusive macros.