Cameron Smith

Given that cmake has moved on since `bob.cmake` was written I think we are due for a more comprehensive and cohesive overhaul. The current approach basically defines a custom interface...

Thank you.

We should probably call this `PUMI_HAS_ZOLTAN` or something like that to prevent conflicts with other packages that have a macro/pre-processor definition for zoltan.

This was added as part of #342.

With the exception of `initial velocity`, all IC appear to be scalar values: https://github.com/SCOREC/core/blob/f12a2cfa9aeb72e188a8c6c23f734534598f58fa/phasta/phBC.cc#L248-L255 I can modify the SimModeler attdefs if that solution makes sense to everyone.

@KennethEJansen I was checking the attribute definition to see how the 'applyScalar' code that Fan found applied. To address the requirements I'm trying to understand how the boundary conditions are...

As suggested, this commit https://github.com/SCOREC/core/commit/776376a2a896f56af5f15e78d9c35f335e1a219e switched the default from off to on and added a `.inp` control `transferParametric` for the user to disable it. So, we should revert `transferParametric` to...

Yeah, the following octave code appears to have no problem with it: ``` (ins)>> A = [[22391.839134, -79303.375391, 44018.262128], [-79303.375391, 294606.941173, -172004.515247], [44018.262128, -172004.515247, 521170.455823]] (ins)>> [v, lambda] = eig(A)...

Hi Andy, Take a look at the PUMI user's guide (https://scorec.rpi.edu/~seol/PUMI.pdf) example on page 77. Specifically, this API call: `pumi_ment_getAdj(e, mesh_dim-1, adj_ents);`

Whoops. OK. I thought this was related to the code with ghosting. Using the apf APIs, the necessary call is here: https://github.com/SCOREC/core/blob/b384d6cef49cda83b8176d2ba860e3a8923ff572/apf/apfMesh.h#L184-L193 edit: `getDownward(...)` should be used, not `getAdjacent(...)`