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.
There was a problem hiding this comment.
Can we just extract a list of unique subregion types from that slice? I am not saying I know how to do it but I am sure we can come up with some meta-programming magic to do that. To be seen if nvcc does not crash while doing that though...
There was a problem hiding this comment.
I thought about that, I wanted to check in here before I invested the time.
There was a problem hiding this comment.
we could also just loop over all subRegions and then have a runtime check on the type inside the dispatch and only launch the kernels if the real type matches the dispatched one. Basically if the subregion cast failsinstead of errorring out we just ignore it.
There was a problem hiding this comment.
That was what I tried at first. Aside from the fact that I imagine there are cases where we would prefer to error out instead of silently proceeding it has the problem that not all subregions have the FiniteElementBase subgroup so the following call will fail
FiniteElementBase & subRegionFE = elementSubRegion.template getReference< FiniteElementBase >( finiteElementName );If we want to go this way we could do the same thing as we do for the constitutive model and allocate a NullFiniteElement class.
There was a problem hiding this comment.
I had not though of that... this is certainly not the most elegant path so let's see if we can come up with something cleaner as we add use cases for this.
There was a problem hiding this comment.
Certainly for now the simplest thing would be to just keep it as is using SUBREGION_TYPES = types::TypeList< CellElementSubRegion >; and then re-evaluate once we have a need for other types.
| @@ -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. |
| "H1_Prism11_VEM_Gauss1" | ||
| ] | ||
| }, | ||
| "explicit": [] |
There was a problem hiding this comment.
@corbett5 Can you put an example here and I will fill out the valid combinations?
There was a problem hiding this comment.
@rrsettgast this is not how it's done, but I'll probably try and change it to accept this format.
"explicit": [
["CellElementSubRegion", "DamageSpectral<ElasticIsotropic>", "H1_Hexahedron_Lagrange1_GaussLegendre2"],
["CellElementSubRegion", "DamageSpectral<ElasticIsotropic>", "H1_Wedge_Lagrange1_Gauss6"]
]
The order of the values should be the same as the order of the vars. In this case this is
"vars": [ "SUBREGION_TYPE", "CONSTITUTIVE_TYPE", "FE_TYPE" ]
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.