[title] could be missleading

[govarguz]

Regarding the title, "GLUE Code: A framework handling communication and interfaces between scales" Here the word "interface" sounds a bit broad, between multiscale simulations there are several types of interfaces, even real physical ones, hence I would suggest to write API explicitly.

Part of https://github.com/openjournals/joss-reviews/issues/4822

[rspavel]

While I definitely agree that "interface" is a very overloaded term, I argue that the GLUE Code goes beyond simple APIs. At a high level this includes using scientific/algorithmic checks and uncertainty quantification to assess the validity of the results being provided. But this also extends to the co-design, particularly on the ICF side, where much of the logic as to whether a "true" multiscale method even makes sense occurs in the GLUECode_Service itself

[govarguz]

yes, you can find a better wording than interface, not necessarily API

[rspavel]

Is this a blocking issue regarding the review? We've used this nomenclature throughout many reports as well as publications (preprint and accepted) and would rather stay consistent. And while I agree that "interface" is an incredibly overloaded term, so is "scale"* and it is really the context that indicates which definition is being used.

*: actually, in this context that simultaneously applies to the granularity of the scientific simulation and the number of nodes the simulation is running across on the cluster. Let's pretend that was being clever...

[govarguz]

This is am open issue, as you see, I suggested API, but if you explain it better than with a very ambiguous word "interface"...go ahead!

[junghans]

I think we should stick with "interface" as the "I" in API stand for interface as well.

[govarguz]

I dislike "interface", because this is not specific. API is certainly more specific, or another less confusing definition.

[rspavel]

I guess I still disagree with that.

As I mentioned, basically every word of that title (except "GLUE") is ambiguous/"not specific". That is just the nature of language. An example I always enjoy is a talk I gave about 8 or 9 years ago where I had to redefine terms such as "process" every few slides due to how overloaded that tends to be.

Code: is this software or an encoding scheme Framework: Is this a methodology? A set of tightly coupled services/systems? Handling Communication: Is this an alternative to MPI? An interface to TCP? Etc Interfaces: As discussed, this could mean a very scientific definition or it could be closer to how "interface" is used in API Scales: As discussed, this could mean we are talking about physical scales or it could mean we are talking about different sized allocations/clusters.

Like most things, it only truly makes sense in the greater context. Because this is a "Code" that implements a "framework", that implies it is closer to software than encoding scheme. Communication, scale, and interface all combine to indicate we are using the more computer science oriented uses of the term. Also, this being submitted to a Journal of Open Source Software further indicates we are using more of a software oriented definition of the word "interface"

And any confusion beyond that is rapidly negated by the contents of the abstract/summary, let alone the rest of the paper.

I am in the process of writing up some text to address #14 and we have already addressed every other issue. Unless we can think of a really good alternative title, I am going to push back against this requested change.

[lubbersnick]

I agree with @rspavel on all of these points. "Interface" and "Scale" in particular serve as useful "puns" that have both computer science and computational science meanings which are both applicable to this work. And also agree that the abstract/summary/paper can clarify. If we could reach the highest levels of linguistic precision in titles alone then abstracts would not be a thing at all. So for my vote I would also say I resist this change.

[govarguz]

@lubbersnick @junghans @rspavel, I did my work, by providing this review! The editor know my comments and If you are improving the abstract, among other parts of GLUE as pointed out in my other issues... well the last word will be with the editor! A last suggestion from my side is: as @lubbersnick said, if you re-write the abstract perhaps you will find a better title, which is a common scientific writing practice.

[danielskatz]

As the editor, I think the current title is ok, but if you can find a way to improve it when you improve the abstract, that would be fine too.

[danielskatz]

thanks to all for the interesting discussion here

[apachalieva]

We made small changes to the "Summary" to improve the readability and understanding of our publication/code.

With this, I am closing this issue. Thank you for all the input and interesting discussion.

[apachalieva]

@govarguz, I can see that you reopened this issue. Can you please, elaborate? We believe that we have discussed the issue with you and the editor (@danielskatz), and it can be closed.

[govarguz]

Closed