JOSS: Other software packages, same job?

[bonh]

In the readme you are stating that

CAD_to_OpenMC is certainly not the only package that tries to solve this problem. Other options include:

cad_to_dagmc
stellarmesher
These two packages solve the same problem as CAD_to_OpenMC, and in fact in many cases are interchangeable. See for instance >> [benchmark-zoo] ( https://github.com/fusion-energy/model_benchmark_zoo ).

In the readme from stellarmesh it says:

Stellarmesh is developed by the original authors of Thea-Energy/stellarmesh, CAD-to-DAGMC, and CAD-to-OpenMC.

These other projects, stellarmesh and cad_to_dagmc, seem to be active, too. And share developers?

I couldn't find any comments about other software packages in the paper. Perhaps you should clarify what makes your package unique?

openjournals/joss-reviews#7710

[jacobmerson]

I agree, I think there needs to be some more details in the documentation about why one should choose one of these packages over the other. Especially since they share developers. Is it just a matter of style, or are there technical differences, etc.

[ebknudsen]

@bonh @jacobmerson To provide a bit of context:
Indeed these other packages that try to solve the same problem, and yes some of us are contributing to more than one of them.
The history is that CAD_to_OpenMC and cad_to_dagmc are of similar age, stellarmesher somewhat newer. Partially stellarmesh was created with an ambition to unify efforts across projects, so far (due to funding and staffing issues) that has not been successful, and so the older packages retain value, and are being actively maintained.

That said - I agree with your comments and will clarify the differences (technical as well as stylistic) in in the text.

[ebknudsen]

@bonh @jcaobmerson I have now tried to put CAD_to_OpenMC and it's design philosophy, in relief to the others. I do hope that is what you were after.

[bonh]

I like the clarification. Few questions/suggestions:

First, it is aimed at working for all step-geometries, with no assumptions on geometry.

I don't get what you mean by "all step-geometries" and "no assumptions on geometry".

Second, it must be relatively easy to add code for a new backend should one wish to do so. From this requirement stems the code-structure as it is, with one frontend and several backend-classes. This may be seen as a measure to enhance the longevity of the project.

Do you mean by "backend" the meshing backends listed in the readme? Perhaps you'd like to clarify this. Further, if you think this is important for your package, perhaps you'd like to change the project structure to more strongly reflect the "frontend"-"backend" relationship? And finally, if you aim for "easy to add code for a new backend" I suggest that you provide a specific example for the user how to do so (subclassing assemblymesher, filling in the required methods, and so on).

Last, it must be easy to extract, generate, and manipulate material tags from the underlying step-model. As models become large and complex, maintaining a separate list of materials, in sequence, is seen as cumbersome and error prone.

Just playing devils advocate here (and I haven't really tried out the other software packages): The other software packages are not able to "extract, generate, and manipulate material tags from the underlying step-model"? To me that sounds like a fundamental functionality of a software package claiming to transform step files into something else.

[ebknudsen]

I like the clarification. Few questions/suggestions:

First, it is aimed at working for all step-geometries, with no assumptions on geometry.

I don't get what you mean by "all step-geometries" and "no assumptions on geometry".
To be very specific, the other (friendly) competing packages come from a fusion background where geometries tend to be radially symmetric (in some manner). The aim for CAD_to_OpenMC is to allow including messy engineering realities, such as piping, while still managing to keep the turn-around time for sims. This is for instance where gmsh may get memory problems, because the entire geometry is considered as a complete block.
We take pains to work around those problems doing one "pipe" at a time.

Second, it must be relatively easy to add code for a new backend should one wish to do so. From this requirement stems the code-structure as it is, with one frontend and several backend-classes. This may be seen as a measure to enhance the longevity of the project.

Do you mean by "backend" the meshing backends listed in the readme? Perhaps you'd like to clarify this. Further, if you think this is important for your package, perhaps you'd like to change the project structure to more strongly reflect the "frontend"-"backend" relationship? And finally, if you aim for "easy to add code for a new backend" I suggest that you provide a specific example for the user how to do so (subclassing assemblymesher, filling in the required methods, and so on).

This is what I mean. Point taken - I will attempt to put together a skeleton for this procedure.

Last, it must be easy to extract, generate, and manipulate material tags from the underlying step-model. As models become large and complex, maintaining a separate list of materials, in sequence, is seen as cumbersome and error prone.

Just playing devils advocate here (and I haven't really tried out the other software packages): The other software packages are not able to "extract, generate, and manipulate material tags from the underlying step-model"? To me that sounds like a fundamental functionality of a software package claiming to transform step files into something else.

If I may be allowed to play devil's advocate myself :-). You are sort of asking me to (in an article about this software) comment on the motives and priorities of other projects and developers, not controlled by me. I honestly don't think I can be expected to speculate on why they have not prioritized a feature that I find fundamental or important, can I?
At the time of writing, the other projects could not meaningfully extract tags from the step-geometry. You could apply a set of defined material tags manually as a list (as is done at https://github.com/fusion-energy/model_benchmark_zoo).
If stellarmesh gets active support again, I'd lobby (in my capacity of a advisor/co-developer) for this kind feature, as I do agree that it is an important and fundamental feature.
Did that make sense to you?