Unit test exe not found

[ikalash]

I'm seeing that the new unit tests

        179 - Albany_Serial_Unit_Test (Failed)
        180 - Albany_Parallel_Unit_Test (Failed)

are failing in the nightlies. It looks like it's due to the executable tests/unit/evaluators/evaluator_unit_tester not being found. @gahansen , do I need to enable something for the executable to build?

[ikalash]

Update on this: it looks like there is a link error in building Albany that causes this issue: https://sems-cdash-son.sandia.gov/cdash/viewBuildError.php?buildid=1131. It's curious that the other tests just fine. This happens in the skybridge build and the spack build. At first I thought my changes to the skybridge scripts yesterday may have caused this issue, so I spent a bunch of time trying to investigate that. Didn't find a problem, and then checked the spack build to find the same problem - so I think it's not the skybridge scripts. I am verifying that right now by using scripts from last Friday on skybridge.

[bartgol]

The link error is because the unit test only links albanyLib, and not LandIce. That's fine if LandIce is not enabled, but if it is, all the landice references in the various factories are broken.

This should be fixed together with #579.

[bartgol]

Note: a quick fix would be to link $ALBANY_LIBRARIES, which in LandIce builds includes also LandIce.

[ikalash]

Thanks @bartgol . I'm confused as to why the issue only showed up in the spack and skybridge nightlies for now, not the others. I thought the unit tests are on by default for now. I can wait for the fix to #579. Maybe I'd turn off the unit tests in the problematic builds for now to avoid the problem.

[bartgol]

I'm not sure why it doesn't show up in all builds that include LandIce. I only know that if you don't enable LandIce, the error is quickly explained.

[ikalash]

The builds where the problem shows up definitely have LandIce enabled. I don't get this...

[bartgol]

Sorry, it's the other way around. If LandIce is enabled, you should expect the link error. If it's not enabled, then I have no answer.

[bartgol]

Nvm, I fixed the undef ref to LandIce stuff, and now it complains about stk stuff undef refs.

Again, this is due to albanyLib depending on albanySTK or any other lib (ugh), so it will be fixed when circular deps are eliminated. For now, we should simply link all albany libs, as we do for the other executables.

[bartgol]

Ah, wait, $ALBANY_LIBRARIES is defined only inside the src subdirectory. We need to list the libs manually (with proper switch on config options), or simply wait till inverse deps are removed...

[gahansen]

I'd suggest we wait for the inverse deps to be removed, we are working on that now so that is probably the best course of action.

Another question along these lines. Any reason that we want to keep the percept code down in STK? There is another library created in there that I do not think is strategic for us after the prune. I can remove that if we do not need it. This code is not maintained, it is a snapshot of stk_percept from many years back. It is used to refine stk meshes after input - if we still want to do that sort of thing we probably need to come up with a maintained mechanism to do that.

[bartgol]

@gahansen I'm currently working on a cyclic removal branch. I also would like to remove all the percept stuff. If there's no objection, I will prune it as part of the branch.

[gahansen]

I have no objections :-)