Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
  • May 04 16:52
    wd15 edited #1248
  • May 04 16:50
    wd15 opened #1248
  • May 04 13:00
    pfhub commented #1247
  • May 04 12:55
    commit-lint[bot] commented #1247
  • May 04 12:55
    commit-lint[bot] commented #1247
  • May 04 12:55
    guyer edited #1247
  • May 04 12:55
    review-notebook-app[bot] commented #1247
  • May 04 12:55
    wd15 opened #1247
  • May 03 13:49
    wd15 assigned #1246
  • Apr 30 18:28
    wd15 review_requested #1246
  • Apr 30 18:27
    wd15 ready_for_review #1246
  • Apr 30 16:02
    wd15 milestoned #1246
  • Apr 30 16:02
    wd15 labeled #1246
  • Apr 30 16:02
    wd15 labeled #1246
  • Apr 30 16:02
    wd15 edited #1246
  • Apr 30 15:47
    pfhub commented #1246
  • Apr 30 15:43
    guyer edited #1246
  • Apr 30 15:43
    commit-lint[bot] commented #1246
  • Apr 30 15:43
    review-notebook-app[bot] commented #1246
  • Apr 30 15:43
    wd15 opened #1246
Daniel Schwen
@dschwen
You'll have steady state after 1e6 and the timestep can grow boundless. So you get a lot of sim time for almost no wall time
I also see that people used unreasonably coarse meshes and very low non-linear solver tolerances
This just encourages a pointless on-upmanship(to quote @laagesen) - and I'm certainly guilty of that with my obsession over 3a
We need to discuss this at the meeting, but I'm in favor of just dropping the "efficiency" plot until we get this right.
The solution could be a well defined architecture (or set of architectures) - A reference desktop and a reference cluster. Preferably an actual physical machine everyone has access to.
or just chuck it altogether
Daniel Schwen
@dschwen
Just looking at the gamut of the 3a MOOSE benchmarks where the slowest MOOSE benchmark is over 6000 times slower than the fastest should make one realize how utterly useless this comparison is.
I am discouraged from working on further uploads but that means that subpar uploads will likely define the perception of our code. Frustrating.
Stephen DeWitt
@stvdwtt
I’m with you on the pitfalls of determining the “efficiency” of a code. I think in most cases, any measure of performance that doesn’t account for accuracy is bound to be misleading. That was one of the main motivations behind BM7 — it gives a well-defined error metric and normalizes the time by the number of cores and the processor clock speed. The normalized clock speed still misses plenty of relevant information though (and encourges single-core runs) and a reference machine would definitely be preferable.
Stephen DeWitt
@stvdwtt
I don't think our joint obession with 3a has been <i>entirely</i> pointless. With the tip velocity there’s an ok error metric. The spread in times that it takes between codes is something that’s worth knowing in an order of magnitude sense. I also think the spread in times for the MOOSE uploads is interesting to the extent that it demonstrates the vast difference between expertly optimized codes/parameter sets vs more naive implementations.
Daniel Schwen
@dschwen
Well, yeah, except, none of the MOOSE codes was "explicitly" optimized
Everything was due to changes in the input file.
Yeah, if the takeway is that a newbie MOOSE user can run a really slow simulation, that's fine with me.
My "crazy idea" was to use a standardized off the shelf computer - a Raspberry Pi - as a reference machine. But I've gotten mixed feedback. In particular that the ARM architecture may not be representative if most simulations in practice are run on x64.
Stephen DeWitt
@stvdwtt
That choices in the input file (for any code) can cause a calculation to take orders of magnitude longer and be less accurate is a useful warning I think
Daniel Schwen
@dschwen
Also, it is hard to know whether the spread is due to a spread in uploader expertise, or due to low user friendlyness (if that is the point to be made here...)
Issue #500 proposes tags for uploads
one tag could be the "level" of familiarity with the code of the uploader
Stephen DeWitt
@stvdwtt
That makes sense to me.
Daniel Schwen
@dschwen
And that might just be a pill to swallow. If you are not familiar with MOOSE you will not get optimal results.
I have a suspicion that this is common problem for scientific codes.
And part of the problem could be that it is easy to get started, where other codes maybe put up a barrier through a steeper learning curve that prevents a quick "shot from the hip"
Stephen DeWitt
@stvdwtt
You’re right, that is hard to know. They can also be hard to separate — if you run an implicit code you need to work harder to pick a time step, choosing that correctly is some mix of expertise and user-friendlieness
Daniel Schwen
@dschwen
preconditioning is a big one for implicit codes
Stephen DeWitt
@stvdwtt
Right, that’s a better example
Daniel Schwen
@dschwen
that is voodoo science even to me
I go with experience
We are still discovering things that make our simulations orders of magnitude faster. Just yesterday @laagesen found a neat trick to speed up phase field simulations with source terms by a factor of >100 (which sounds insane...)
Stephen DeWitt
@stvdwtt
That does sound insane (nice job @laagesen)
drjamesawarren
@drjamesawarren
Wow.
There’s some stuff on operator spitting I did a while ago that might be relevant. Could be fun to discuss at the workshop.
Daniel Schwen
@dschwen
That does not sound sanitary
drjamesawarren
@drjamesawarren
Heh
Daniel Wheeler
@wd15
Regarding the efficiency plots, maybe the the wall time should be reported at a particular simulation time. I think we should change that.
Daniel Wheeler
@wd15
Possible having the plot could contain some more information such as cpu time and number of cores. Also, wall time versus inverse of the number of cores as another plot so bottom left corner indicates better performance per core.
I do need to implement tags. It would help a lot.
A. M. Jokisaari
@amjokisaari
Wow, that was a lot to catch up on. I think we need to set aside some time at the meeting to have this discussion. Daniel and/or Steve, perhaps one of you can bring a summary of the points discussed here to the meeting and we can then brainstorm additional alternative?
Stephen DeWitt
@stvdwtt
@dschwen, since you kicked this off, I’ll defer to you if you want to summarize this at the meeting
Daniel Schwen
@dschwen
sure, I can do that
Daniel Schwen
@dschwen
The agenda schedules the pfhub update to thursday morning (small timeslot followed by the @tonkmr presentation). We should probably rather talk about this in a breakout session.
Daniel Wheeler
@wd15
@amjokisaari, any chance that you can sign off on the paper (or not)? I implemented most of your changes.
A. M. Jokisaari
@amjokisaari
I'll take a look now. Is there a PDF built?
oh, i see you added it :+1:
Daniel Wheeler
@wd15
Thanks to both you and Mike on the feedback. It improved things a lot.
Daniel Wheeler
@wd15
@guyer set up a Slack group for us all to try, pfhub.slack.com
I'll try and add as many as I can
sulemansulemansuleman
@sulemansulemansuleman
hello every one . I need a PFC phase field crystal modeling code in matlab language if possible some one give me clue
Daniel Schwen
@dschwen
This book has matlab / octave examples.
sulemansulemansuleman
@sulemansulemansuleman
yes i am doing in matlab \but at initial days still dnt know exactly what to do how to write PFC code
if someone guide me \i will be very thankfull