Ten years challenge: fermions at unitarity
Original article: https://journals.aps.org/prl/abstract/10.1103/PhysRevLett.96.160402 Preprint, ungated: https://arxiv.org/abs/cond-mat/0602224
PDF URL: https://github.com/ev-br/unitarity_repro/blob/repro_unitarity/article.pdf Metadata URL: https://github.com/ev-br/unitarity_repro/blob/repro_unitarity/metadata.yaml Code URL: https://github.com/ev-br/10yr_repro_challenge_35/releases/tag/v1.1
Scientific domain: Physics Programming language: Fortran / Python Suggested editor:
This is paper 36 in https://github.com/ReScience/ten-years/issues/1
Thanks for your (late) submission :) We'll assign an editor soon.
@pdebuyl Can you handle this submission (Physics/Python/Fortran) for the Ten Years Reproducibility Challenge (only # reviewer needed) ?
As editor thus?
@pdebuyl Yes, sorry, I should have explained.
ok
I mean, "I will edit" :-)
@jochym could you review the submission here? If this is your first review for ReScience, I will guide you through the process.
@dombrno could you review the submission here? If this is your first review for ReScience, I will guide you through the process.
@vahtras will review the paper. Thank you Olav!
ping @vahtras
@berquist would you review the submission "fermions at unitarity" for ReScience ? If this is your first review for ReScience, I will guide you through the process.
Is there a howto for reviewers @pdebuyl ?
Hi @vahtras
We have reviewer guidelines here: https://rescience.github.io/edit/
The most specific part of the review, in relation to ReScience, is to actually run the code and verify the claims of reproduction that are stated in the article.
Specifically for the ten-year challenge
- We only require one reviewer.
- The requirement to have a readable and reusable code are relaxed a bit. It would make little sense for the authors of this issue to perform a full modernization of their code.
- The author should provide in the article their reflection on the longevity, quality and retrievable character of their old code and of the corresponding environment (language, platform-specific code, proprietary tools, etc).
In this specific case, rerunning the full set of calculations might not be very practical, since it's going to require a non-negligible cpu time on a cluster. Not sure what are implications though.
How many core-hours ? (or core-days / node-days depending on the hardware you have used)?
The largest runs in the supplement repository are some 120 CPU hours on 24 cores. Multiply it by about 1.5-2 for thermalization. Smaller system sizes are much faster, some 4-10 cpu hours each, if a partial verification is OK. (rerun small system sizes on the reviewer's machine, rerun the fits with a mix of reviewer's data and my data or somesuch).
Well, this seems indeed costly. @vahtras do you have the resources for the small systems verification? (4-10 cpu hours each) ? I could execute that if necessary.
Hi all,
I see only now that the review process is frozen here. @vahtras what do you think of the computational requirements?
I apologize for the delay, will have some time for a look now.
On Thu, Jul 30, 2020 at 10:10 PM Pierre de Buyl [email protected] wrote:
Hi all,
I see only now that the review process is frozen here. @vahtras https://github.com/vahtras what do you think of the computational requirements?
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/ReScience/submissions/issues/42#issuecomment-666660150, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABLLJBN4U7N25L6JXIOCHODR6HHTHANCNFSM4M3DOYCA .
Hi @vahtras thank you for getting back to us :-) Other papers are still in the pipeline, so this should be ok.
Anything needed from me at this stage?
I think we're waiting for @vahtras review (gentle pressure :) )
@vahtras do you still plan to review the article?
Yes, finally. First question: the makefile has been hardcoded for Intel compilers. Does it build with GNU?
It certainly does. https://github.com/ev-br/10yr_repro_challenge_35/commit/837038f2461ee5e17da895388bda935749918e0c is the relevant makefile.
I then simply commented it out when transferring to cluster/intel compiler instead of adding platform detection (more brittle stuff to debug ten years down the line)
The change from gnu on a laptop to intel on cluster is here: https://github.com/ev-br/10yr_repro_challenge_35/commit/3603020b726cd6eab0db18d03c687d9237d757d7
EDIT:the switch from gnu to intel is https://github.com/ev-br/10yr_repro_challenge_35/commit/acc29743ec4f0d49da013c48db2ef36e0a48cb50
@pdebuyl Any progress?
Hi @rougier sorry about this. @vahtras is this still doable for you? In the meantime, I will try to find another reviewer.
please find another reviewer
On Tue, Jun 22, 2021 at 8:56 AM Pierre de Buyl @.***> wrote:
Hi @rougier https://github.com/rougier sorry about this. @vahtras https://github.com/vahtras is this still doable for you? In the meantime, I will try to find another reviewer.
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/ReScience/submissions/issues/42#issuecomment-865649687, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABLLJBL3JZMRVAZIML5KY3DTUAX27ANCNFSM4M3DOYCA .
@pdebuyl I think you need to find a new reviewer. You can use the @ ReScience/reviewers notification if necessary.
@rougier I have started to do so.
Good. Any progress?