Creating an embedded syntax in MCNP comments

[MicahGale]

So this has come up a few times, and I am personally kind of conflicted about it. The fundamental issue is that MCNP input syntax is rather lossy, you can't name or tag cells, surfaces, etc.
That is the role of comments,
however, when your input is not being directly accessed these comments have less utility.
In the past have been proposal to add names to objects #76.

So the idea I am contemplating: adding support for embedding a markup language in c style comments.
Likely contenders would be JSON and YAML as of writing. This might look like:

c {"name": "foo"
c "deplete": true }
1 2 3

or

c name: foo
c children: 
c    - 1

The downside to yaml is this would be totally valid and confusing:

c name: foo
   c children: 
c    - 1

Here are some thoughts I've been having:

Pros

• Allows adding additional information such as names
• A script that works on MCNP files could use this to combine all input files into.
  • for instance a depletion coupling script could have the timesteps in JSON at the start of the file, and any cell that is being depleted would just need to be flagged, eliminating the need to keep up to date long lists of cell numbers.

Cons

• Nested syntax is error prone
• This feels just a bit hacky. I have seen internal tools that tried to add use this feature, and it just felt hacky, and error-prone
• syntax highlighting won't work out of the box. Because now you have to support create a new subniche syntax.
• What do you do if something looks like your markup language but isn't? Do you freak out? Then you effectively are banning people from using markup like syntax in a comment, which should be inherently fre-form.
  • Then again this is a lot of documentation comments. Though those have devoted syntax e.g. /** */ or /// Could we create something like c c or c $ or c /** .... c */

[SterlingButters]

I'm a fan of this idea though I'm not sure I understand all the details of your pro/con list. My suggestion would be introduce the possibility of attaching a python dictionary associated with any particular surface/cell/etc object. When MontePy writes the input deck, the dictionary would precede the line defining the surface/cell (however this could get weird if the user adds additional comments immediately preceding the line that defines the cell/surface and tries to read the input deck back into MontePy - for that reason I'm actually more of a fan of putting the dictionary in the same line with $).

For example:

1 PX 10.0. $ {key1: val1, key2: val2, ...}

You could have some standardised keys of course but I think the user should have some additional flexibility. This would permit the user to sort objects based on completely arbitrary criteria as well.

Everything said, I don't think you need a new mini-markup syntax - if the next non-space character after $ is { (and there is a termination } then read it as a dictionary associated with that object.

[MicahGale]

One major con that has been brought up is: data could get desynchronized.

The most important alternative option is: serialization with #193. This would allow the data to be more consistent and would allow all this additional data.

I think I am of the mind that this is the ultimately solution: don't hack, go with the flow.

[SterlingButters]

True, for some properties it might not matter but I could see it as problematic for others

[MicahGale]

I think the ultimate solution is to have MCNP move to JSON, YAML, etc., and have the schema be flexible so additional metadata can be added but just ignored.

[SterlingButters]

I don't see necessarily how this prevents desynchronisation of additional data though - unless the assumption is that the MontePy json is the exclusive "source of truth" for the MCNP problem/input.

[MicahGale]

With having it just be one file you are less likely to have people editing the file in multiple ways. Generally they would only go through the API. Whereas with an embedded syntax you know someone will edit it in MontePy then years later someone else will edit it in a text editor and have no clue what the JSON is doing and may accidentally break it.

[SterlingButters]

Right so "exclusive" use of the API is what is assumed

[tjlaboss]

Comment syntax is a dangerous drug. Once you start down the dark path, forever will it dominate your destiny. The thought makes me feel mopey. Comment syntax: not even once.

MontePy should always read and write pure MCNP. A once-through tool that uses MontePy may be an acceptable place for an embedded syntax in MCNP comments, just as there are legitimate pharmaceutical applications for otherwise harmful substances.

[MicahGale]

Yes I agree with this sentiment, and I think I will close this as a forbidden fruit task.