Removing ALBANY_EPETRA_EXE ifdef around distributed response / parameters code about albany HOT 5 CLOSED

The ALBANY_EPETRA ifedefs guard are mainly used to guard Epetra code. If you see parts that are guarded but do not include Epetra code than they can probably be removed. I see this as part of the refactoring to Tpetra, not sure why you see this as a separate issue.

from albany.

This issue was motivated by some confusion on my part regarding the code regarding something specific with the distributed parameters code -- maybe you can explain this to me. Are the specializations templated on PHAL::AlbanyTraits::DistParamDeriv, Traits meant to work when ALBANY_EPETRA_EXE is off? If you look at the code, some of these specializations have ALBANY_EPETRA_EXE guards (the ones that use Epetra objects from the workset, as expected), and some don't. I am wondering if it is safe for me to remove ALBANY_EPETRA_EXE ifdef guards around new code I checked in today that is Epetra-free, or if this is going to cause issues in a no-Epetra build. It seems to me like there should be issues when using distributed parameters when Epetra is turned off b/c, for example, there are ifdef guards in critical functions in PHAL_SeparableScatterScalarResponse_Def.hpp; yet my tests that use distributed parameters run correctly even when Epetra is off.

from albany.

I am wondering if it is safe for me to remove ALBANY_EPETRA_EXE ifdef guards around new code I checked in today that is Epetra-free, or if this is going to cause issues in a no-Epetra build.

I don't know. I guess we should try and see.

It seems to me like there should be issues when using distributed parameters when Epetra is turned off b/c, for example, there are ifdef guards in critical functions in PHAL_SeparableScatterScalarResponse_Def.hpp; yet my tests that use distributed parameters run correctly even when Epetra is off.

There might even be some code that is not used any longer, or maybe in the Tpetra version there is some missing logic so that not all the parts of the sensitivities are computed (but that should not be caused by ifdef guards). I guess it is probably better to first figure out what's wrong with the ATO tests and then we can try to clean the #ifdef guards.

from albany.

I see. This is along the lines of what I was conjecturing. I'll keep this open for a bit until I understand better the behavior with ATO. Then I agree this can be closed and moved to the infrastructure cleanup task/issue.

from albany.

Closing this issue - it will be moved to general Albany infrastructure cleanup issue / task.

from albany.