Proposal: `particlePushParameters` Attribute

[steindev]

Similar to the fieldSolverParameters attribute, which is mandatory if fieldSolver = other, a particlePushParameters attribute could be added. This should be mandatory if the particlePush attribute is other such that additional descriptions are possible.

[ax3l]

Thanks for the suggestion.

Another more compact solution we use in other places is to use the same field, but only defined the prefix other:. For example: particlePush value other:somethingThatIsUnspecifiedButCanBeAnythingUntilTheNextVersionGivesItAName - why not also spaces? Everything is possible and easy to parse that way.

Would that also work for you? :)

[steindev]

Would that also work for you? :)

Sure! Just stumbled across it and it felt like it was forgotten. With your solution, I like that it is specified and compliant with the standard already!

I would be fine with closing the issue.

[sbastrakov]

@ax3l I think it's a nice convention. However, is it documented somewhere in the standard files? From looking here does not seem compliant, as it says only other is a valid option, not other:[text]

[PrometheusPi]

@ax3l Would giving a non-standard string like other: Higuera-Cary break any open-PMD analysis tools etc. that run specific checks?

[ax3l]

Not that I am aware of, that's the idea with the prefix.

[PrometheusPi]

Okay

[psychocoderHPC]

I suggest to use json after ":" instead of an arbitrary string behind.

other: JSON

And openPMD should define useful basic tags you can optimally use e.g. description, dio, name

other : {"name": "MyOwnPusher", "description": "Is more stable.", doi: "123-122" }

But maybe the word other should be fully removed and the string should become always a valid json string.

[ax3l]

That's also a good idea. The point with other prefix is, that you can literally write anything behind it in a non-Standard Format until a new revision of the standard is out. So you could use json.

It's probably just not worth it to standardize those other formats further, since we can add new keywords in patch level releases.

[PrometheusPi]

@ax3l Okay - so the strings defined by the standard should be interpreted as prefixes and can be extended by any string - is this idea somewhere mentioned in the standard? (I could not find it.)