-
-
Notifications
You must be signed in to change notification settings - Fork 41
[REVIEW]: FAME-Core: An open Framework for distributed Agent-based Modelling of Energy systems #5087
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
Comments
Hello humans, I'm @editorialbot, a robot that can help you with some common editorial tasks. For a list of things I can do to help you, just type:
For example, to regenerate the paper pdf after making changes in the paper's md or bib files, type:
|
|
Wordcount for |
|
Review checklist for @pgranatoConflict of interest
Code of Conduct
General checks
Functionality
Documentation
Software paper
|
Review checklist for @xtruanConflict of interest
Code of Conduct
General checks
Functionality
Documentation
Software paper
|
In general I find it difficult to review the project FAME-code in itself as it should be reviewed and analyzed taking into account the entire FAME-framework. I have a few comments or questions related to the review items.
I'm assuming that the submitting author (KriNiTi) is actually Kristina Nienhaus, but this is just a wild guess, since the GitHub account doesn't provide additional identification elements.
The paper claims "In single-core mode, FAME-Core executes the AMIRIS model with low overhead – performing a simulation of the German wholesale electricity market for one year in hourly resolution on a desktop computer within about 20 seconds. In multi-core mode, FAME demonstrated high parallelisation efficiency for a setup of 16 computationally heavy agents: Computation wall time was roughly proportional to 1/𝑛 as 𝑛 ∈ 1, 2, 4, 8 cores were utilised."
In general the installation is well documented and the project follows industrial standards. I managed to install FAME-core and, as suggested, FAME-demo.
The FAME-demo shows basic functional features of the the software. An extensive analysis should be carried on to assess every aspect of the claimed functionalities. It's important to take into account that FAME-core is part of a broader software suite, part of which is currently under review for JOSS.
The claimed performace are basically the same claimed on #5041
I guess that the AMIRIS project under review on #5041 should be considered a real-world analysis problem. But since we are here reviewing FAME-code I guess at least a more explicit reference to AMIRIS should be made. The FAME-demo project is also a good usage example (even though a not real-world one).
There is a wiki shared by all the projects of the FAME suite (https://gitlab.com/fame-framework/wiki/-/wikis/home).
Authors list several other ABM frameworks and claim that they evaluated more than 40 other software but beside that there is no proper comparison. That said, personally, I don't think there is the strict need of an analytical comparison to justify the existence of a new ABM framework and therefore I judge the requirement fulfilled but nonetheless I pointed this out for the sake of the public discussion. Last note. |
@pgranato : Thanks for your effort so far. Regarding your question "The paper claims "In single-core mode, FAME-Core executes the AMIRIS model with low overhead – performing a simulation of the German wholesale electricity market for one year in hourly resolution on a desktop computer within about 20 seconds. In multi-core mode, FAME demonstrated high parallelisation efficiency for a setup of 16 computationally heavy agents: Computation wall time was roughly proportional to 1/𝑛 as 𝑛 ∈ 1, 2, 4, 8 cores were utilised." I think this could be rather crosschecked by reviewers of #5041 . |
Dear @pgranato & @fraukewiese thank you for your comments. Please find our response below:
Kristina Nienhaus was leading the software project in which the original FAME code was created (originally not hosted on Gitlab). Most of the code was indeed written by me (Christoph Schimeczek). Kristina submitted the paper to JOSS on my behalf as I was leaving for a longer period of holidays just days before we got clearance to submit it. I am sorry if this latter issue caused confusion. I will serve as contact person from now on.
We agree that it makes sense to consider the general runtime of AMIRIS as original result of the AMIRIS paper. However, we originally intended to make performance claims for FAME-Core regarding “low overhead” & “parallelization efficiency” in this paper using AMIRIS as an example. Since FAME-Core is the execution library of AMIRIS, the former is in fact co-responsible for its runtime. If you think this is not appropriate or confusing to keep it that way, we suggest the following to amend it: we could provide a dedicated performance testing suite for FAME-Core if you would be willing to verify our claims (Please note that this requires open-mpi compiled with Java)? If you think you could check that, we would provide such a suite of tests to measure parallelization efficiency and overhead of FAME - although it might take a few days to write that suite...
Thanks for pointing this out. The mentioned file & tedious setup process is no longer required. We updated the README accordingly (as newer information was only available on the Wiki).
FAME-demo already uses most functional features of FAME-Core, including scheduling, messaging, input & output management. Do you require further demonstration of functionalities? If so, we would be happy to include additional examples, code or agents within the FAME-Demo project to demonstrate FAME-Core functionality.
Our original idea was not to make claims about FAME-Io or AMIRIS, but to hint at the low overhead of FAME-Core and its parallelizability (see also our comment at
We plan to have a direct reference to JOSS paper of AMIRIS currently under review #5041. The idea is to publish all three papers simultaneously, such that they directly refer to each other. Besides that, would you recommend a longer text describing AMIRIS in the FAME-Core paper as well? Should we add further references to peer-reviewed applications of AMIRIS or do you think the current text suffices?
We also want to point out the API documentation. Since it was easy to miss we added a corresponding badge in the repository.
We have this comparison available and could add text & tables. However, we originally thought this might blow up the paper and would be out of scope for a JOSS publication. Would you recommend a) including texts, tables and references to other frameworks, b) keep the text as is, or c) drop the reference to other frameworks completely?
Do you think we should include both diagrams in this paper of FAME-Core, or would you recommend to keep the current diagram, thus complementing the FAME-Io paper #4958? |
That's fine for me. Checked out this point.
Unfortunately I will not be able to check the suggested performance testing suite. I agree with @fraukewiese that this claim can be cross checked by AMIRIS on #5041
Ok, checked.
I think that having the three papers published simultaneously (and referencing each other) solves much of this questions and should be enough for the readers to understand the general concepts of the framework, functionalities and performance claims.
Thanks. Checked.
I guess that a short paragraph or a small table that briefly describes the comparison with the few you closely analyzed should be added replacing "We closely examined, e.g., Jade, MASS, Repast and Akka."
Since the paper are going to be published together I recommend to keep the current diagram. |
@dlr-cjs |
Dear @fraukewiese & @pgranato, we rewrote the "Statement of need" to include a more detailed examination of the frameworks we assessed and why we decided to create FAME. We hope that our changes address your comments appropriately. |
@editorialbot generate pdf |
@editorialbot commands |
Hello @pgranato, here are the things you can ask me to do:
|
@pgranato : Do you think your comment regarding the statement of need it is addressed adequately? |
Hi @fraukewiese, yes I think that this version of the article clarifies sufficiently the state of the field and the need of a new software. |
Hi @xtruan : Could you update us on how the review is going? Thanks a lot :) |
Hey sorry for being the slowpoke here, I will get my review completed by the end of this week! |
Done! Archive is now 10.5281/zenodo.7755760 |
@editorialbot recommend-accept |
|
@editorialbot recommend-accept |
|
|
👋 @openjournals/pe-eics, this paper is ready to be accepted and published. Check final proof 👉📄 Download article If the paper PDF and the deposit XML files look good in openjournals/joss-papers#4118, then you can now move forward with accepting the submission by compiling again with the command |
Hello @Krinit @dlr-cjs, as with the other papers, I made some formatting changes to the paper: https://gitlab.com/fame-framework/fame-core/-/merge_requests/69 Could you merge these? |
Thank you @kyleniemeyer for your formatting changes. I merge them as requested. |
@editorialbot generate pdf |
@editorialbot accept |
|
Ensure proper citation by uploading a plain text CITATION.cff file to the default branch of your repository. If using GitHub, a Cite this repository menu will appear in the About section, containing both APA and BibTeX formats. When exported to Zotero using a browser plugin, Zotero will automatically create an entry using the information contained in the .cff file. You can copy the contents for your CITATION.cff file here: CITATION.cff
If the repository is not hosted on GitHub, a .cff file can still be uploaded to set your preferred citation. Users will be able to manually copy and paste the citation. |
🐦🐦🐦 👉 Tweet for this paper 👈 🐦🐦🐦 |
🐘🐘🐘 👉 Toot for this paper 👈 🐘🐘🐘 |
🚨🚨🚨 THIS IS NOT A DRILL, YOU HAVE JUST ACCEPTED A PAPER INTO JOSS! 🚨🚨🚨 Here's what you must now do:
Any issues? Notify your editorial technical team... |
Congratulations @KriNiTi and @dlr-cjs on your article's publication in JOSS! Thanks so much to @xtruan and @pgranato for reviewing this, and @fraukewiese for editing. |
🎉🎉🎉 Congratulations on your paper acceptance! 🎉🎉🎉 If you would like to include a link to your paper from your README use the following code snippets:
This is how it will look in your documentation: We need your help! The Journal of Open Source Software is a community-run journal and relies upon volunteer effort. If you'd like to support us please consider doing either one (or both) of the the following:
|
Submitting author: @KriNiTi (Kristina Nienhaus)
Repository: https://gitlab.com/fame-framework/fame-core
Branch with paper.md (empty if default branch): 86-publish-paper
Version: v1.4.2
Editor: @fraukewiese
Reviewers: @xtruan, @pgranato
Archive: 10.5281/zenodo.7755760
Status
Status badge code:
Reviewers and authors:
Please avoid lengthy details of difficulties in the review thread. Instead, please create a new issue in the target repository and link to those issues (especially acceptance-blockers) by leaving comments in the review thread below. (For completists: if the target issue tracker is also on GitHub, linking the review thread in the issue or vice versa will create corresponding breadcrumb trails in the link target.)
Reviewer instructions & questions
@xtruan & @pgranato, your review will be checklist based. Each of you will have a separate checklist that you should update when carrying out your review.
First of all you need to run this command in a separate comment to create the checklist:
The reviewer guidelines are available here: https://joss.readthedocs.io/en/latest/reviewer_guidelines.html. Any questions/concerns please let @fraukewiese know.
✨ Please start on your review when you are able, and be sure to complete your review in the next six weeks, at the very latest ✨
Checklists
📝 Checklist for @pgranato
📝 Checklist for @xtruan
The text was updated successfully, but these errors were encountered: