Make participant names in precice-aste-run configurable

[davidscn]

The names of the participants are currently hard-coded to A and B when investigating mappings. It would be easy to read actual names from the CLI and use it for the coupled simulation, i.e., for preCICE and the preCICE xml configuration.

aste/src/modes.cpp

Lines 204 to 205 in e796634

	if (participantName == "A") {
	asteConfiguration.participantName = "A";

[kursatyurt]

As far as I remember, A is used for the donor participant, and B is used for the acceptor participant.

We can change it as follows easily if it does not look messy

From

precice-aste-run -v -p A --mesh fine_mesh_nn --data "Franke Function" &
precice-aste-run -v -p B --mesh ../coarse_mesh --output map_nn --data "InterpolatedData"

to

precice-aste-run -v --donor -p ParticipantName1 --mesh fine_mesh_nn --data "Franke Function" &
precice-aste-run  -v --acceptor -p ParticipantName2  --mesh ../coarse_mesh --output map_nn --data "InterpolatedData"

Any suggestions for the roles?

[davidscn]

Wouldn't it be possible to deduce this information from the xml config?

[kursatyurt]

We have a similar discussion for replay mode and finalize it with another configuration file. Replay mode can be used as a fully configurable mapping-tester mode.

[davidscn]

@uekerman any opinions here?

• Option 1: would be to use a json config file to the replay aste (we could potentially still preserve the CLI as it is right now, which is a bit easier to handle via the command line).
• Option 2: rename the participant command line argument to --first and --second in order to distinguish send and receive
• Option 3: use hasMesh (Remove hasMesh and hasData precice#1251) in order to deduce the information automatically. This might be unsafe depending on which configs we expect to operate successfully on.

[uekerman]

Option 2 is probably a good quick solution. I like the names.
In the long run it would be good if all use cases of ASTE could merge, so Option 1. You probably have the better overview of all potential pitfalls here.