JOSS paper

[bonh]

I hope I get that right, but you are using the diffuse interface method solely to represent a solid interface, right? In that case, I suggest that you differentiate strongly from the diffuse interface methods used for multiphase flows (most often where both phases are fluid). To avoid confusion. For example, I failed to find the term "diffuse interface method", which you are using in the paper, in the article by (Nguyen et al. 2018).

[bonh]

Continuing from above:

Finally, OpenCMP provides the only publicly available implementation of the diffuse interface method.

I find that statement difficult to accept (which does not mean that I am correct here!). The diffuse interface method is to my best knowledge a very broad concept describing a lot of possible equations and implementations. I guess, often the Cahn-Hilliard or Allen-Cahn equations are referenced that way. However, to proof your statement wrong I just have to find one single, public available (what do you mean by public, for example?) implementation (which includes some github code snippets?), even with low quality?

https://mooseframework.inl.gov/source/kernels/CahnHilliard.html, https://fenicsproject.org/olddocs/dolfin/1.3.0/python/demo/documented/cahn-hilliard/python/documentation.html, and a snippet https://github.com/urbainvaes/cahn-hilliard (which I have not tested, it is four years old! I am just suggesting, that merely implementing some diffuse interface method is trivial!)

I asked about your diffuse interface method before in #7: "You mention that there are no other implementations of the diffuse interface method. Is that really correct? How about the Phase Field implementation of comsol? Can that not be used to simulate "hard" boundaries by choosing super high values for density and viscosity or so?" and you answered: "To our knowledge, this is the only open-source implementation of the diffuse interface method with stabilization for Dirichlet boundary conditions (see Nguyen(2018))." By stabilization for Dirichlet boundary conditions do you mean the weak implementation of strong bcs using Nitsche's method?

You continue with: "What you are describing with Comsol's phase field model would not straightforward to implement, would not be stable when using Dirichlet BCs, and is not open-source." I am still not getting the different between your approach of the diffuse interface method and just increasing the density and viscosity in Comsol. Do you suggest that the stability of the numerical procedure used by comsol is insufficient for such a problem?

[bonh]

I remember that the other reviewer did find the usage of the term "multiphysics" not exactly suitable. I cannot find your discussion about that point right now (can you show me?). I guess it is somewhat an issue of how to define that term but do you agree with the definition provided on the wikipedia page https://en.wikipedia.org/wiki/Multiphysics_simulation?

[nasserma]

I hope I get that right, but you are using the diffuse interface method solely to represent a solid interface, right? In that case, I suggest that you differentiate strongly from the diffuse interface methods used for multiphase flows (most often where both phases are fluid). To avoid confusion. For example, I failed to find the term "diffuse interface method", which you are using in the paper, in the article by (Nguyen et al. 2018).

This is a pretty complicated topic to address here, but we did address it in Elizabeth's paper quite well. There is a great deal of variation of the use of the term diffuse interface in the literature. What we are doing is similar to what is done to simulation segregated flows when the indicator field is meant to approximate the interface from a numerical perspective, so a continuous immersed boundary method, versus approximating the interface from a physical perspective, such as a continuous phase field model (e.g. Cahn-Hilliard). From my understanding, there is a significant conceptual difference between immersed boundary numerical methods and phase field models. The former are typically used to approximate a sharp-interface, which is possibly evolving and deforming, while the latter are physical models which must conserve mass, momentum, energy and include interfacial energy.

[bonh]

In my opinion the statement of need is very long. The "first barrier" you are observing is present, I generally agree, but your are not completely solving it. So I suggest that instead of using very general and broad statements like "MOOSE [...] and FEniCS [...] have very steep learning curves and are inaccessible to the general scientific and engineering communities.", "One such barrier is a lack of suitable software accessible to the general scientific and engineering community." or "the predominance of the finite volume method for fluid dynamics simulations inherently limits simulation accuracy for a given mesh compared to the finite element method" you pinpoint what your software really wants to improve. With that paragraph you have the whole community crying "not true at all, Sir!" :-D.

[bonh]

There is a great deal of variation of the use of the term diffuse interface in the literature.

I totally agree! I just think that if you are able to define it more sharply (pun intended) your paper improves. Perhaps use a footnote or something?

[nasserma]

I remember that the other reviewer did find the usage of the term "multiphysics" not exactly suitable. I cannot find your discussion about that point right now (can you show me?). I guess it is somewhat an issue of how to define that term but do you agree with the definition provided on the wikipedia page https://en.wikipedia.org/wiki/Multiphysics_simulation?

Regarding the Wikipedia definition, I think it provides a reasonable definition, for example from it "simultaneous simulation of the physical stress on an object and the temperature distribution of the object would be considered a multiphysics simulation". This describes a simulation involving conservation of momentum and conservation of energy.

Regarding the discussion with the other reviewer, please see here,

https://github.com/openjournals/joss-reviews/issues/3742#issuecomment-937759257

[bonh]

I do remember a discussion about adding a figure and a brief simulation study to the paper, right? I think that would be really valuable and I suggest you use the diffuse interface test case, perhaps together with NS and heat transfer? Would that be possible?

[bonh]

This describes a simulation involving conservation of momentum and conservation of energy.

So is tutorial 9 both of them? I am not really aware of that yet...

[nasserma]

I am going to add a section over the weekend which provides high-level summarizes of the key examples, linking to their detailed summaries on our website. I will not have anymore time until later today, but I am going to try to summarize all of the revisions from this thread that I will work on over the weekend. If you could confirm that I get things right tonight or tomorrow AM, I would appreciate it. That way Monday's revision is as close to what is desired as feasible.

[nasserma]

I am running behind on this, will try to finish the revision tomorrow and will push to the publication branch.

[nasserma]

This describes a simulation involving conservation of momentum and conservation of energy.

So is tutorial 9 both of them? I am not really aware of that yet...

Please see tutorial 8 for the convection/reaction/diffusion example, I rearranged the tutorials with the last revision.

[nasserma]

In my opinion the statement of need is very long. The "first barrier" you are observing is present, I generally agree, but your are not completely solving it. So I suggest that instead of using very general and broad statements like "MOOSE [...] and FEniCS [...] have very steep learning curves and are inaccessible to the general scientific and engineering communities.", "One such barrier is a lack of suitable software accessible to the general scientific and engineering community." or "the predominance of the finite volume method for fluid dynamics simulations inherently limits simulation accuracy for a given mesh compared to the finite element method" you pinpoint what your software really wants to improve. With that paragraph you have the whole community crying "not true at all, Sir!" :-D.

So i am still working on the revised paper, but I think we have addressed all of the concerns from this thread. Given that there is a controversial paragraph in the Statement of Need section, I want to get some feedback before pushing all of the changes. This could save some back and forth,

However, there are several barriers to more wide spread use of simulations. One such barrier is the lack of user-friendly finite element-based open-source simulation software. Many of the most widely-used computational multiphysics software packages, such as COMSOL Multiphysics [@comsol] or ANSYS Fluent [@fluent], are closed-source and cost-prohibitive. Furthermore, the predominance of the finite volume method for fluid dynamics simulations inherently limits simulation accuracy for a given mesh compared to the finite element method [@Ferziger2002]. Many high-quality open-source packages exist which use the finite element method, such as the computational multiphysics software MOOSE [@Permann2020] or the finite element libraries NGSolve [@ngsolve] and FEniCS [@Alnaes2015]. However, they require that the user has a relatively detailed understanding of the finite element method, such as derivation of the weak formulation of the problem, along with programming background. Alternatively, open-source finite volume-based packages such OpenFOAM and SU2 are more accessible to the broader scientific and engineering community in that they require a less detailed understanding of numerical methods and programming, instead requiring an understanding of the command line interface (CLI) and configuration through a set of configuration files.

[nasserma]

I realize that some of the statements might still be controversial, but I really think there is a big difference between the accessibility and user-friendliness of software designed to be libraries/frameworks (MOOSE, FEnICS, NGSolve, et al) versus those which have a CLI-based user interface (OpenFOAM, SU2, et al). Many scientists and engineers do not have the programming and numerical methods background to use the former, and tend to use the latter.

Separately there are a few GUI-based open-source multiphysics packages, such as Elmer, but I have not found them as conducive to large-scale research simulations as the ones previously listed.

[bonh]

This is a pretty complicated topic to address here, but we did address it in Elizabeth's paper quite well. There is a great deal of variation of the use of the term diffuse interface in the literature. What we are doing is similar to what is done to simulation segregated flows when the indicator field is meant to approximate the interface from a numerical perspective, so a continuous immersed boundary method, versus approximating the interface from a physical perspective, such as a continuous phase field model (e.g. Cahn-Hilliard). From my understanding, there is a significant conceptual difference between immersed boundary numerical methods and phase field models. The former are typically used to approximate a sharp-interface, which is possibly evolving and deforming, while the latter are physical models which must conserve mass, momentum, energy and include interfacial energy.

That's a really interesting viewpoint and I think I am getting what you aiming for. I agree that there is a conceptual difference, however, I cannot really spot a mathematical difference between phase field models and diffuse interface method as immersed boundary method. I guess, that if the same terms are used for different things in slightly different fields of research you might want to add a footnote to clarify your vocabulary. Otherwise, as I said above, I think, reader might have the wrong expectation about your code.

[bonh]

I do remember a discussion about adding a figure and a brief simulation study to the paper, right? I think that would be really valuable and I suggest you use the diffuse interface test case, perhaps together with NS and heat transfer? Would that be possible?

Please see tutorial 8 for the convection/reaction/diffusion example, I rearranged the tutorials with the last revision.

I like tutorial 8! But you are not using your diffuse interface method to represent the "pillars", right? Why not? I think such an example would be really great for your code, i.e., multiphysics plus immersed boundary method.

[bonh]

So i am still working on the revised paper, but I think we have addressed all of the concerns from this thread. Given that there is a controversial paragraph in the Statement of Need section, I want to get some feedback before pushing all of the changes. This could save some back and forth,

Sorry, I did not get that, now it's too late I will comment on what you wrote in the paper, right?

[bonh]

It just came to my mind, that accessibility is really important to you, so why not add it to the title of your paper? Just an idea, do not really have anything else to add.

[bonh]

I do remember a discussion about adding a figure and a brief simulation study to the paper, right? I think that would be really valuable[...].

Did I miss something here? Why do you not add a color figure and a tutorial case to your paper? I think the editor agreed somewhere that you do not have to be strictly below the word count limit.

[bonh]

However, there are several barriers to more wide spread use of simulations. One such barrier is a lack of suitable software accessible to the general scientific and engineering community. Many of the most widely-used computational multiphysics software packages, such as COMSOL Multiphysics (COMSOL Multiphysics ®, n.d.) or ANSYS Fluent (Ansys ® 40 Fluent, n.d.), are closed-source and cost-prohibitive. Furthermore, the predominance of the finite volume method for fluid dynamics simulations inherently limits simulation accuracy for a given mesh compared to the finite element method (Ferziger & Perić, 2002). Open-source packages that uses the finite element method, such as the computational multiphysics software MOOSE (Permann et al., 2020) or the finite element libraries NGSolve (Schöberl, 2020) and FEniCS (Alnaes et al., 2015), have very steep learning curves and are inaccessible to the general scientific and engineering communities.

I am fine if you want to keep that section in that way (which means it will not prevent my recommendation to publish the paper), but I really recommend you don't! As I said before how you formulate your very broad statements will anger quite a few people, I guess, and steer away the attention from the advantages your software actually is providing. Let me walk through every sentence above (and I am playing the devil's advocate here):

However, there are several barriers to more wide spread use of simulations.

Okay.

One such barrier is a lack of suitable software accessible to the general scientific and engineering community.

What do you mean by suitable? It follows next, I guess (closed-source, cost, finite volume, steep learning curve).

Many of the most widely-used computationathousendsl multiphysics software packages, such as COMSOL Multiphysics (COMSOL Multiphysics ®, n.d.) or ANSYS Fluent (Ansys ® 40 Fluent, n.d.), are closed-source and cost-prohibitive.

Why does closed-source mean that a software is not "suitable" to the general scientific and engineering community? If you look for papers and industry projects which use comsol and fluent you will find many, many successful projects, right? Secondly, in my experience, cost of software is not a strong argument for industry (missing support is however!). So what do you mean with "general scientific and engineering community"? Do you exclude industry? thousends

Furthermore, the predominance of the finite volume method for fluid dynamics simulations inherently limits simulation accuracy for a given mesh compared to the finite element method (Ferziger & Perić, 2002).

That is a very strong statement! Is that really true? As far as I know, the finite volume method is somewhat similar to the Discontinuous Galerkin method which is somewhat similar to the finite volume method. What page are you referring to in the book by Ferziger? If your statement is true, there have to be advantages of the finite volume method (mass conservation, for example?) against fem, otherwise, a whole bunch of mathematical research groups are wasting there time and grants?! Seems unlikely...

Open-source packages that uses the finite element method, such as the computational multiphysics software MOOSE (Permann et al., 2020) or the finite element libraries NGSolve (Schöberl, 2020) and FEniCS (Alnaes et al., 2015), have very steep learning curves and are inaccessible to the general scientific and engineering communities.

This is a very subjective statement. Why are the learning curves steep? And calling a software inaccessible is almost insulting, and most likely untrue, because these software packages have thousands of users and successful projects.

You do not have to answer the questions I posed above. I asked them to give you a feeling what readers of your paper might thing while reading your statement of need. And of course I might be wrong!

[bonh]

Please, please comment on my second post from 16 days ago. I still think that my questions are very valid!

[Alex-Vasile]

I do remember a discussion about adding a figure and a brief simulation study to the paper, right? I think that would be really valuable and I suggest you use the diffuse interface test case, perhaps together with NS and heat transfer? Would that be possible?

Please see tutorial 8 for the convection/reaction/diffusion example, I rearranged the tutorials with the last revision.

I like tutorial 8! But you are not using your diffuse interface method to represent the "pillars", right? Why not? I think such an example would be really great for your code, i.e., multiphysics plus immersed boundary method.

That is a good idea, we will definitely include a diffuse interface version alongside of it.

The reason it hasn't been included yet is because we are still working on the diffuse interface version of that model.

[nasserma]

Please, please comment on my second post from 16 days ago. I still think that my questions are very valid!

I'm sorry, I though I responded to everything prior to your new posts from a few days again, could you explicitly mention which comment that you are referring to?

I guess, that if the same terms are used for different things in slightly different fields of research you might want to add a footnote to clarify your vocabulary. Otherwise, as I said above, I think, reader might have the wrong expectation about your code.

I will add a statement that refers to two reviews which provide background on different the terminology,

https://doi.org/10.1146/annurev.fluid.37.061903.17574 https://doi.org/10.1146/annurev.fluid.30.1.139

Again, there is no clear definitive usage of this terminology across disciplines and sub-disciplines, but I think providing these references will provide users with some additional clarity.

I like tutorial 8! But you are not using your diffuse interface method to represent the "pillars", right? Why not? I think such an example would be really great for your code, i.e., multiphysics plus immersed boundary method.

As @Alex-Vasile mentioned, we are still working on implementing DI method for the multicomponent Navier-Stokes solver, but for Tutorial 8 we would need to change it to a 3D problem to see any real benefit from the DI method.

Did I miss something here? Why do you not add a color figure and a tutorial case to your paper? I think the editor agreed somewhere that you do not have to be strictly below the word count limit.

We did, please see the updated version of the manuscript.

It just came to my mind, that accessibility is really important to you, so why not add it to the title of your paper? Just an idea, do not really have anything else to add.

Accessibility means something very specific at our university (and in Canada), so I would not be comfortable using it in the title of our paper since there is no way to specify exactly what we mean. We will add a statement or two in the manuscript regarding this, though, hopefully that will address your comment.

[nasserma]

Here I am going through your Devil's Advocate comment above sequentially:

One such barrier is a lack of suitable software accessible to the general scientific and engineering community.

What do you mean by suitable? It follows next, I guess (closed-source, cost, finite volume, steep learning curve).

Exactly, the following statements clarify and expand on this initial claim.

Many of the most widely-used computationathousendsl multiphysics software packages, such as COMSOL Multiphysics (COMSOL Multiphysics ®, n.d.) or ANSYS Fluent (Ansys ® 40 Fluent, n.d.), are closed-source and cost-prohibitive.

Why does closed-source mean that a software is not "suitable" to the general scientific and engineering community? If you look for papers and industry projects which use comsol and fluent you will find many, many successful projects, right? Secondly, in my experience, cost of software is not a strong argument for industry (missing support is however!). So what do you mean with "general scientific and engineering community"? Do you exclude industry? thousends

It depends on what you define as a "successful" project, but if we are performing research, closed-source software involves software implementations that are not accessible and, therefore, not reproducible. While there are plenty of research publications in which closed-source software is used, clearly there is an issue when research methods are used that are not documented and verified.

Regarding cost, I have over 10 years of experience with industry both through academic-industry partnerships and engineering consulting. I cannot agree with you at all on this point, based on my own experience and what has been communicated by many of my colleagues and collaborators.

Furthermore, the predominance of the finite volume method for fluid dynamics simulations inherently limits simulation accuracy for a given mesh compared to the finite element method (Ferziger & Perić, 2002).

That is a very strong statement! Is that really true? As far as I know, the finite volume method is somewhat similar to the Discontinuous Galerkin method which is somewhat similar to the finite volume method. What page are you referring to in the book by Ferziger? If your statement is true, there have to be advantages of the finite volume method (mass conservation, for example?) against fem, otherwise, a whole bunch of mathematical research groups are wasting there time and grants?! Seems unlikely...

The finite-volume method is, essentially, a zeroth order discontinuous Galerkin method, so the statement is strictly true since DG enables the use of higher-order elements. If you look in the applied math literature, there is a great deal of work on DG and hybrid DG methods. I lent my copy of Ferziger to one of my students, but I will respond shortly with the exact section along with many other references to support this claim after consulting with my colleague in Applied Math whose research is focused on hybrid DG.

Open-source packages that uses the finite element method, such as the computational multiphysics software MOOSE (Permann et al., 2020) or the finite element libraries NGSolve (Schöberl, 2020) and FEniCS (Alnaes et al., 2015), have very steep learning curves and are inaccessible to the general scientific and engineering communities.

This is a very subjective statement. Why are the learning curves steep? And calling a software inaccessible is almost insulting, and most likely untrue, because these software packages have thousands of users and successful projects.

We tried to be clear in the revision, the need to know a programming language itself can easily be considered a steep learning curve. OpenCMP requires understanding of the CLI, editing configuration files, etc, but no need to know Python or have a detailed understanding of the numerical methods "under the hood". There is no insult intended and no claims that these different packages are problematic, in fact, we use one of them extensively in OpenCMP.

[bonh]

I am talking about that one:

I find that statement difficult to accept (which does not mean that I am correct here!). The diffuse interface method is to my best knowledge a very broad concept describing a lot of possible equations and implementations. I guess, often the Cahn-Hilliard or Allen-Cahn equations are referenced that way. However, to proof your statement wrong I just have to find one single, public available (what do you mean by public, for example?) implementation (which includes some github code snippets?), even with low quality?

https://mooseframework.inl.gov/source/kernels/CahnHilliard.html, https://fenicsproject.org/olddocs/dolfin/1.3.0/python/demo/documented/cahn-hilliard/python/documentation.html, and a snippet https://github.com/urbainvaes/cahn-hilliard (which I have not tested, it is four years old! I am just suggesting, that merely implementing some diffuse interface method is trivial!)

I asked about your diffuse interface method before in https://github.com/uw-comphys/opencmp/issues/7: "You mention that there are no other implementations of the diffuse interface method. Is that really correct? How about the Phase Field implementation of comsol? Can that not be used to simulate "hard" boundaries by choosing super high values for density and viscosity or so?" and you answered: "To our knowledge, this is the only open-source implementation of the diffuse interface method with stabilization for DiricYou continue with: "What you are describing with Comsol's phase field model would not straightforward to implement, would not be stable when using Dirichlet BCs, and is not open-source." I am still not getting the different between your approach of the diffuse interface method and just increasing the density and viscosity in Comsol. Do you suggest that the stability of the numerical procedure used by comsol is insufficient for such a problem?hlet boundary conditions (see Nguyen(2018))."

By stabilization for Dirichlet boundary conditions do you mean the weak implementation of strong bcs using Nitsche's method?

You continue with: "What you are describing with Comsol's phase field model would not straightforward to implement, would not be stable when using Dirichlet BCs, and is not open-source." I am still not getting the different between your approach of the diffuse interface method and just increasing the density and viscosity in Comsol. Do you suggest that the stability of the numerical procedure used by comsol is insufficient for such a problem?

[bonh]

As @Alex-Vasile mentioned, we are still working on implementing DI method for the multicomponent Navier-Stokes solver, but for Tutorial 8 we would need to change it to a 3D problem to see any real benefit from the DI method.

So do you want to add it before the paper gets published? If that is the case I think this would be an excellent example to discuss in your paper!

[bonh]

Mhhh, I really do not see a color figure or a description of any tutorial case in the new revision of the paper. I am confused...

Can you upload a pdf? To exclude that the compilation is wrong.

[bonh]

The remainder of you answer is very satisfying and helpful, thank you!

[nasserma]

Mhhh, I really do not see a color figure or a description of any tutorial case in the new revision of the paper. I am confused...

Can you upload a pdf? To exclude that the compilation is wrong.

I am super-confused, I get an updated PDF when I use the JOSS Paper Preview link https://whedon.theoj.org/

Please give me an hour or so to determine what is wrong.

[bonh]

Oh no, was I actually commenting on an old version of your paper?! I did not check the revision number - I am so sorry!

[nasserma]

It is due to some issue in the Github compilation, please see my latest comment in the review thread, you'll have to use the preview service until then. But yes, we almost got into a discussion based on the original submission and not the current one that (hopefully) addresses most of your comments!

[bonh]

The only thing open about the paper for me now is https://github.com/uw-comphys/opencmp/issues/22#issuecomment-1056968759. I am really interested in your thoughts!

[nasserma]

We removed this statement in the revised manuscript based on your concerns. While, in the context of what we mean by the "diffuse interface method" I think our statement is correct, your point that this can be interpreted much more widely is definitely a point of confusion that would require readers (unreasonably) to both completely understand and agree with our terminology.

The revised statement now reads "Finally, OpenCMP provides a publicly available implementation of the diffuse interface method with support for stabilized Dirichlet boundary conditions (Nguyen et al., 2018)."

Later in your comment, you talk about using Comsol's phase field model to capture a complex fluid/solid interface through using a very large viscosity for the solid phase. I have not used this before, although I have used Comsol's general PDE module and other FEM libraries to solve the Cahn-Hilliard model. If we were to generalize to the Cahn-Hilliard/Navier Stokes model (at least, a specific version of it), it would not be very simple to impose general boundary conditions as you can with an immersed boundary method (continuous or discontinuous). There is a free energy that is minimized to formulate conservation of mass and momentum, the terms associated with the interface are derived indirectly, so you would need to find a free energy expression that is both physically relevant and results in the desired fluid/solid boundary conditions. With a numerical method for imposing boundary conditions at a fluid/solid interface, you can simply impose them directly without having to model the solid phase. Does that make sense?

[bonh]

Mhh, yes, that clarifies it a lot. It is a difficult problem for sure! I am done here, thank you!