Compiling apps together

[rtaylo45]

Hello,

I have a problem were I am compiling two moose apps together and i am getting a linking error:

Linking Library /home/qt5/projects/mole/test/lib/libmole_test-opt.la...
libtool:   error: cannot find the library '/home/qt5/projects/mole/test/lib/libmole_test-opt.la' or unhandled argument '/home/qt5/projects/mole/test/lib/libmole_test-opt.la'

This is what my make file looks like:

# Set up MOOSE framework
ifeq ($(wildcard $(MOOSE_DIR)/framework/Makefile),)
  $(error MOOSE framework was not found!  Please set MOOSE_DIR to the MOOSE directory!)
endif
FRAMEWORK_DIR      := $(MOOSE_DIR)/framework
include $(FRAMEWORK_DIR)/build.mk
include $(FRAMEWORK_DIR)/moose.mk

################################## MODULES ####################################
# To use certain physics included with MOOSE, set variables below to
# yes as needed.  Or set ALL_MODULES to yes to turn on everything (overrides
# other set variables).

ALL_MODULES                 := no

CHEMICAL_REACTIONS          := yes
CONTACT                     := no
EXTERNAL_PETSC_SOLVER       := no
FLUID_PROPERTIES            := no
FUNCTIONAL_EXPANSION_TOOLS  := no
HEAT_CONDUCTION             := no
LEVEL_SET                   := yes
MISC                        := no
NAVIER_STOKES               := no
PHASE_FIELD                 := yes
POROUS_FLOW                 := no
RDG                         := no
RICHARDS                    := no
SOLID_MECHANICS             := no
STOCHASTIC_TOOLS            := no
TENSOR_MECHANICS            := no
XFEM                        := no

# Modify modules for SAM
ifneq ($(wildcard $(SAM_DIR)/Makefile),)
  # Sam will need these modules
  FLUID_PROPERTIES := yes
  HEAT_CONDUCTION  := yes
  TENSOR_MECHANICS := yes
endif

include $(MOOSE_DIR)/modules/modules.mk

############################## SAM ############################################
ifneq ($(wildcard $(SAM_DIR)/Makefile),)
  APPLICATION_DIR     := ${SAM_DIR}
  APPLICATION_NAME    := sam
  BUILD_EXEC          := yes
  include             $(FRAMEWORK_DIR)/app.mk
  ADDITIONAL_INCLUDES += -I$(SAM_DIR)/include/base
  ADDITIONAL_CPPFLAGS += -DSAM_ENABLED
  ADDITIONAL_LIBS     += $(SAM_DIR)/lib/libsam-$(METHOD).la
endif

############################## MOLE ############################################
APPLICATION_DIR    := $(CURDIR)
APPLICATION_NAME   := mole
BUILD_EXEC         := yes
GEN_REVISION       := no
DEP_APPS           := $(shell $(FRAMEWORK_DIR)/scripts/find_dep_apps.py $(APPLICATION_NAME))
include            $(FRAMEWORK_DIR)/app.mk

###############################################################################
# Additional special case targets should be added here

I thought i got this working a few months ago but I can't remember if i did anything to the Makefile. Im compiling both codes with MOOSE commit 00fa7c0.

[GiudGiud]

I think you may be missing
BUILD_TEST_OBJECTS_LIB := yes in your if_SAM loop
?

Guillaume

[GiudGiud]

you should not need that, but I just went to check and BlueCrab (the ultimate combined app) does that (inheriting from SamApp too).
So it is what it is..
Ok glad to hear that. Please let us know if any more issues arise

[aarograh]

@GiudGiud (or any other MOOSE dev) I have been working with @rtaylo45 and others on development of our Mole app. This issue has arisen again because we are attempting to couple with several different codes. and a couple different developers ended up pursuing this different ways.

I have a couple questions. First, a "clean" moleApp will have class moleApp : public MooseApp and class moleTestApp : public MooseApp. As Zack mentioned, we modified the first of those to be class moleApp : public SamApp. What I don't understand is this: moleTestApp can properly use moleApp objects just fine, but it cannot use SamApp objects (unless we have it also inherit from SamApp). However, moleTestApp does not inherit from moleApp. I do not understand why it can successfully use all the mole objects but cannot use the Sam objects? Especially since moleApp does all the objects and app registrations for Sam as well. If you could provide some additional clarity on exactly what the expectations are, that woudl be helpful. I want to prevent this kind of thing:

#ifdef APP1_ENABLED && APP2_ENABLED && APP3_ENABLED
  class moleApp : public app1, public app2, public app3
#elseif APP1_ENABLED && APP2_ENABLED
  class moleApp : public app1, public app2
#elseif APP1_ENABLED && APP3_ENABLED
  class moleApp : public app1, public app3
...
etc.
...

Obviously that gets silly after awhile. And furthermore, having to make this same set of changes in both moleApp and moleTestApp is 1) annoying and redundant, and 2) confusing to me.

The second question I have concerns the test objects. It's unclear to me exactly what kinds of objects this might be? I'm envisioning special post-processors, problems, or executioners to operate the application in an abnormal way for testing, but I've never made use of such a setup. Is there useful documentation/examples of what such test objects might be? It's possible that we may not use them, in which case we may take the simple approach of modifying main.C to just use moleApp instead of moleTestApp. However, I do not want to make this change without first understanding possible issues we may encounter as a results.

[GiudGiud]

Hello

A partial response to your questions:

• If you dont do this:

#ifdef APP1_ENABLED && APP2_ENABLED && APP3_ENABLED
  class moleApp : public app1, public app2, public app3
#elseif APP1_ENABLED && APP2_ENABLED
  class moleApp : public app1, public app2
#elseif APP1_ENABLED && APP3_ENABLED
  class moleApp : public app1, public app3
...
etc.

how is the compiler going to know what a SamApp is when Sam is not enabled?
If you choose to work with inheritance (and one alternative is dynamic loading), then you have to do this imo.
@andrsd may advise you better here, he is in charge of another combined application.

Note that for the test app, it calls the registering routines from the main app, see there for example
https://github.com/idaholab/TMAP8/blob/devel/test/src/base/TMAPTestApp.C

I dont see why test apps could not inherit from the main app, but i have not tried this setup.

• Test objects are for reaching hard-to-reach statements in the code, to make sure they work. We really need them.
  You can see a bunch of them in moose/test/src

[aarograh]

For the first point, you're right, we have to do that for now. It's just annoying to do it in two places (moleApp and moleTestApp). It would make more sense to me if we could have moleTestApp inherit from moleApp, but for some reason it cannot identify the samApp objects when we do that. I'd like to understand why this isn't working.

I think switching to dynamic loading might be the better approach long term, but we haven't worked that out yet. Are their any guides/examples that we could look at to try this?

And we can check out the test objects in moose to see some examples. Thanks for pointing us in that direction.

[GiudGiud]

If it fails to identify the samApp objects, then something went wrong during registration.
When you tried to inherit from MoleApp with MoleTestApp, what did you MoleTestApp registerApps and registerAll look like?

There arent many applications doing this because it is brittle when the two apps have been build with different MOOSE versions. There's not much documentation about it, I would just look at the tests for it in the misc module.
You do it like this:

[Problem]
  register_objects_from = 'PhaseFieldApp'
  library_path = '../../../../../phase_field/lib'
[]