Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Review of the paper for JOSS #158

Closed
rboman opened this issue Jan 12, 2024 · 3 comments
Closed

Review of the paper for JOSS #158

rboman opened this issue Jan 12, 2024 · 3 comments
Assignees

Comments

@rboman
Copy link

rboman commented Jan 12, 2024

Here are my comments about the publication in JOSS
(see openjournals/joss-reviews#6200 )

Summary:

  • Since the reader could be a non-specialist, I would recommend starting the paper by a basic description of process (quick description of a rolling mill as the series of units involving rollers of different shapes, etc.), as you would do for your non-engineer friends. It would also be useful to explain what the word "groove" refers to in the process.
  • line 8: wire => wires
  • line 14: could you provide the reader with some examples of "accompanying processes"? (cooling, transport, rotation? maybe something else...)
  • line 23: (remark) One of the main industrial advantages of the plugin system of PyRolL is that it gives the possibility to companies to develop models that are kept "private". I don't know if it may be underlined here, since the journal promotes open-source software; but, from my point of view, this is a really interesting feature for private companies.
  • The summary lacks a quick description of the usual inputs and outputs of the simulation code. For example: the inputs are "the initial shape of the section of the workpiece with all its initial mechanical properties" and "the pass sequence, which consists in a detailed description of the series of rolling units". The outputs are: "the evolution of the section profile along the machine, the thermomechanical state of the material, the rolling forces and torques, etc." This would help the non-specialist (engineer) understand what the code is able to compute.
  • Once again, for the same reason, I think it would be interesting to describe in a few words some features added by the plugins (tool deformation, friction laws, thermal effects, more complex rheology of the workpiece, etc).

Statement of need:

  • line 25 (about optimisation): One advantage of the software which is not put forward in the text is the fact that its architecture (a set of python modules) makes optimisation loops very easy to set up. Indeed, the architecture of PyRolL is very modern if I compare it to what I am used to seeing today in the industry (matlab, fortran, ..., excel!) and it runs very fast thanks to the choice of analytic / semi-analytic models.
  • line 35-53: I have had a look at some of the cited references. I am not a specialist of "long products", but the bibliography seems complete or, at least, sufficient to have a very detailed view of the state of the art.
  • lines 55-73 (about the FEM): I am surprised to see the length of this part of the text. From my point of view, the FEM leads to a completely different kind of numerical models which are much more expensive (several order of magnitude) and the purpose of which is completely different. PyRolL is focussed on a fast (almost instantaneous) solution of the full rolling mill. This kind of simulation is still extremely difficult to do with the finite element method today. It would require billions of unknowns, remeshing and months of cpu time for a single simulation, making optimization unaffordable (even a basic sensitivity analysis). Thus I would not spend too much time comparing PyRolL with FE codes, unless you plan to include a FE solver in it in the future.
@axtimhaus
Copy link
Member

Thanks for your review. I understand the tenor of your suggestions and I basically agree with them. We will look to merge them as soon as possible!

They accompany with those of @philipcardiff in pyroll-project/pyroll-docs#8 for the docs.

@axtimhaus
Copy link
Member

axtimhaus commented Jan 15, 2024

I have regarded your statements in 027b28b.

Especially for the FEM part:
Yes, we generally target on fast models and do not try to compete with the depth and accuracy of FEM, but they are currently widely used and something like the top dog. We are always requested to compare with them.
I shortened the paragraph and focused more on the difference to us to clarify that. Also I stated, that including a FE kernel is generally possible and planned, but currently low priority.

@rboman
Copy link
Author

rboman commented Jan 15, 2024

@axtimhaus thanks! As far as I am concerned, I don't have other comments.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants