Handle API change between Cubit/Trelis 16 and 17 #61
Conversation
| @@ -33,6 +33,7 @@ option(BUILD_DAGMC_EXPORTER "Include DagMC export capability." ON ) | |||
| option(BUILD_MCNP_IMPORTER "Include MCNP import capability." ON ) | |||
| option(BUILD_IGEOM "Include iGeom." OFF) | |||
| option(BUILD_IGEOM_TESTS "Include tests for iGeom." OFF) | |||
| option(CUBIT_17 "Using a version of Trelis or Cubit >= 17.0" OFF) | |||
There was a problem hiding this comment.
Sadly, Cubit and Trelis numbering is a little messy. Is it true that Cubit > 17, or is it just Trelis that is? According to cubit.sandia.gov, the newest version of Cubit is 15.6. I don't know what to do about that since CoreForm refuses to give me a clear answer on how these are related.
Maybe there is an API number that we can refer to? It doesn't really matter except for clear communication to those who will try to build this.
There was a problem hiding this comment.
I'm honestly not sure what version of Cubit this might apply to.
Maybe there is an API number that we can refer to? It doesn't really matter except for clear communication to those who will try to build this.
I wish!! I looked in the * .cmake files of the 17.1 SDK for a version or API number but I didn't see one.
There was a problem hiding this comment.
Sorry, neither of those replies are particularly helpful. The only thing I can think of is to update the docstring on that option to indicate that this should be based on the SDK version being used as someone building the plugin is sure to know what version that is.
There was a problem hiding this comment.
🤦 They definitely do have a version header we can use. @ljacobson64 found it and is using it in #64.
Still doesn't quite answer the question about Cubit vs. Trelis Version numbering though...
There was a problem hiding this comment.
I don't think my PR has any relation to this specific conversation. The only difference between my PR and this one is that instead of telling users to specify whether their version of Trelis is >= 17, it tells users to specify their version of Trelis, and CMake internally determines whether that version is >= 17.
There was a problem hiding this comment.
My assumption about Cubit vs. Trelis version numbering is that they're the same. If you look in /opt/Trelis-XX.X/include/util/CubitVersion.h, it defines both CUBIT_VERSION and TRELIS_VERSION to the same thing
There was a problem hiding this comment.
Perhaps we could use CubitVersion.h to get the version?
There was a problem hiding this comment.
Ah, yeah I should've looked at #64 more closely. I assumed that was what you were doing, and, ideally, I think we probably should do just that -- detect the version from CubitVersion.h. That header is provided by the SDK, so we'd then be assuming that the SDK was matched with an appropriate version of Cubit/Trelis, but given that the headers defining the API are also provided with the SDK I think this is the best we can do. We'll just have to trust that someone applying the SDK to their version of Cubit/Trelis is using the right one and has installed it correctly.
pshriwise
force-pushed
the
igeom_cubit_17_plus
branch
from
a9b3464 to
e70f748
Compare
|
Closing this in favor of #64. |
Added a CMake option to address #60. I was hoping to be able to check
Cubit_VERSIONand do this automatically, but I was a little floored to learn that the Trelis SDK doesn't provide a version number as part of theCubitConfig.cmake(or any of the other.cmakefiles for that matter). It's probably possible to parse the version number out of something else, so if someone has an elegant solution along those lines please feel free to chime in. In the meantime I've sent an email about this to Coreform to see if they will provide this version info in the future.Disclaimer: I've tested that this works for Trelis 17.1 but not for Trelis 16.X so if someone would be willing that would be great.