MueLu: How to pass primal/dual mapping to InterfaceMappingTransferFactory?

[mayrmt]

Question

@trilinos/muelu @kliegeois

I'm trying to understand how I can pass the information on the mapping of dual nodes to primal nodes for the InterfaceMappingTransferFactory introduced in PR #6931 for our application. I'm looking at the example in packages/muelu/test/meshtying/MeshTyingBlocked_SimpleSmoother.cpp.

As in the example, I want to read the preconditioner configuration from an xml-file. In contrast to the example, I want to create the preonditioner via MueLu::CreateXpetraPreconditioner().

The necessary information is set on the parameter list as shown here:

Trilinos/packages/muelu/test/meshtying/MeshTyingBlocked_SimpleSmoother.cpp

Lines 211 to 215 in 29bf4e7

	RCP<ParameterList> params = Teuchos::getParametersFromXmlFile(xmlFile);
	RCP<ParameterList> paramsF, paramsI;
	paramsF = sublist(params, "Factories");
	paramsI = sublist(paramsF, "myInterfaceAggs2");
	paramsI->set<RCP<std::map<LO, LO>>>("DualNodeID2PrimalNodeID - level 0", rcpFromRef(myLagr2Dof));

As far as I understand, this hard-codes the requires the sublist being named myInterfaceAggs2. However, the name of this list is defined in the xml-file as a user-specified string, so there's no guarantee that the user uses that particular name in every xml-file.

@kliegeois How can I pass the primal/dual node mapping to MueLu in a way, where I do not rely on particular sublist names in the MueLu xml-file?

[kliegeois]

Basically, what we need is the factory InterfaceAggregationFactory to have access to DualNodeID2PrimalNodeID - level 0.

In the example, as you said, I hard coded the InterfaceAggregationFactory to be named as myInterfaceAggs2.

I see two approaches not to hard code the name:

• Give the name of the InterfaceAggregationFactory using a variable, possibly defined at the beginning of the xml file.
• Scan the xml file, and keep the name of the (last) InterfaceAggregationFactory.

I think that the last approach would be better as it does not rely on the user to add other information (the name of the factory).
The only drawback would be that this prevents us from using 2 InterfaceAggregationFactory but I do not see any reason for doing that right now.

[mayrmt]

@kliegeois I like the second option better as well. There might be another: maybe this data also can be passed in via the "user data" sublist, similar to the fine-level nullspace and coordinate information.

@lucbv What do you think? Is this the intended use case of the "user data" sublist?

[lucbv]

@mayrmt
Yes you can put that list on "user data" and recover it in your factory. I did not want to block @kliegeois previous PR because of that but the temptation was strong x)
Also if you really want a lot of flexibility you can pass a std::string to the interface factory (using the xml file) that tells you the name of the variable on "user data" to recover in case you have more than one interface.
I am not sure this last bit is the right design but that's at least possible and better than scanning the xml file entirely...

[kliegeois]

@lucbv thanks for your input. That's definitely better.
Next time, feel free to block a PR if it can be improved!

[mayrmt]

@lucbv Thanks! I'll look into that. Maybe we can briefly talk about it later, so that you can point me to an example.

[tawiesn]

@mayrmt @kliegeois I like the idea with the "user data". This has been introduced for such things at some point, but i forgot about it.
However, there is still the implicit assumption that we only have one InterfaceMappingTransferFactory that consumes this information. But that's probably fine.

[mayrmt]

Well, then I’ll give the “user data” sublist a try.

@tawiesn For my application, one InterfaceAggregationFactory is sufficient for now. I guess that even multiple mortar interfaces can be handled, if all interfaces use the same mortar configuration.

@kliegeois Are there any concerns or objections from your side?

[kliegeois]

@mayrmt It is definitely possible to have only one InterfaceAggregationFactory and have multiple mortar interfaces. I have tests in my application code which test those cases.

I have no concerns at all, thanks for looking into that!

[mayrmt]

@lucbv @tawiesn I'm putting the required data RCP<std::map<LO, LO>> myLagr2Dof on the "user data" parameter list as follows:

params->sublist("user data").set<RCP<std::map<LO, LO>>>("DualNodeID2PrimalNodeID", rcpFromRef(myLagr2Dof));

Now, I need to retrieve it during MueLu setup, but how?

To avoid errors such as

Throw test that evaluated to true: !IsKey(fac, ename)
"DualNodeID2PrimalNodeID" not found

I need to stick this data on the fine level. Is

1. extracting non-serializable data
2. adding non-serializable data to the hierarchy

the correct approach? Are there any others?

[lucbv]

@mayrmt that seems reasonable to me, I am not sure that there many other options to handle that use case?

[mayrmt]

@lucbv I'll try that and let you know of my success. Or failure. 😉

[mayrmt]

Has been addressed in #7194. Closing.