Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
    Roland Haas
    @rhaas80
    l" fix (eg the error estimator).
    Erik Schnetter
    @eschnett
    z4c is working for me. maybe i have some changes in the cuda branch?
    should we merge the vertex-centring or the cuda branch first? if you open a pull request, we can merge, and i can then update the cuda branch.
    Roland Haas
    @rhaas80
    do you use mesh refinement?
    fails during regrid for me (and I (have to) disable restrict_during_sync).
    Erik Schnetter
    @eschnett
    i ran the sample "qc0.rpar" parameter file. that uses AMR.
    i see an CarpetX::regrid_every = 0 setting
    i'll submit a new simulation without that setting.
    Roland Haas
    @rhaas80
    note that we added (I think) the Weyl and Multipole thorns.
    Z4c alone might have worked.
    well... I also had to hack Coordinates since otherwise CarpetX complains that vcoord would be invlaid in the ghosts and outer boundaries after a restrict (again this is with regrid_during_sync = no, which I need since some things run in postrestrict and they must apply outer-boundareis which must sync. So running restrict in sync leads to an infinite loop).
    Erik Schnetter
    @eschnett
    i'll try with Weyl.
    no, you want restrict_during_sync = yes
    ooh
    i keep outer boundaries and syncs separate. first sync, then apply outer boundaries.
    ... and with all the clever self-check mechanisms we now have infinite recursion??? well done, erik.
    Erik Schnetter
    @eschnett
    i see the weyl error as well: -> MakeNewLevelFromCoarse before prolongation: Grid function "WEYL::g4tt" is invalid on refinement level 0, time level 0; required [int:VAL,outer:VAL,ghosts:VAL], found [int:INV,outer:INV,ghosts:INV],why{int:MakeNewLevelFromScratch,outer:MakeNewLevelFromScratch,ghosts:MakeNewLevelFromScratch}
    Roland Haas
    @rhaas80
    yes, fixing that one likely starts the decent down the rabbit hole. the qc0Test branch should show them all.
    I think that for this one I ended up having to schedule the Weyl function in postinitial (initial won't do b/c it needs Z4c bssn->adm to get eg admbase::dtkxx unless you want to use an after z4c_poststep in weyl)
    then you need z4c's poststep in initial of course ...
    Erik Schnetter
    @eschnett
    i have fixes for Weyl and Z4c to correct this. smallish.
    Roland Haas
    @rhaas80
    ok
    Erik Schnetter
    @eschnett
    @rhaas80 regarding backtraces in CarpetLib: i don't recall, and i don't think i wrote that code.
    Roland Haas
    @rhaas80
    f06c356c "CarpetLib: Clean up backtrace generation" of carpet says is your's. The commit extends the list from just signals 6 (abort) and 11 (segfault) to QUIT, ILL, ABRT, FPE, BUS in the process removing SEGV. I'll add back SEGV given that it was present in 2012 since the removal see
    ms to be an accident.
    *yours
    Roland Haas
    @rhaas80
    since the azure based test seem to not have been running (at least the ought to have reported errors) I added CarpetX to the ET Jenkins instance at: https://build-test.barrywardell.net/job/CarpetX/ (user: Albert passed: Einstein it's only password protected due to Jenkins security risks to bots whom I assume are unlikely to listen in to this chat.). Builds but currently fails in the prolongation tests (on master)
    .
    Erik Schnetter
    @eschnett
    i have a pull request for a new function CCTK_FullGroupName. Trust me, you've been wanting this. https://bitbucket.org/einsteintoolkit/tickets/issues/2498/new-function-cctk_fullgroupname
    Roland Haas
    @rhaas80
    :-)
    mbabiuc
    @mbabiuc
    @rhaas80 thank you for sending me the Power Ticket. What is the deadline for review? One paper I'm aware of is arXiv:1708.0294.
    @eschnett have you had the chance to set up simfactory on ThornyFlat?
    Erik Schnetter
    @eschnett
    @mbabiuc thanks for sending the reminder this morning! unfortunately i have not yet had time. i received access a few days ago, but didn't log in yet. i'll probably get to it tomorrow.
    Roland Haas
    @rhaas80
    @mbabiuc: Zach Etienne is release manager so he sets the deadline. Looking at his notes on https://docs.einsteintoolkit.org/et-docs/Release_Details the important details would be:
    2021-03-01: all codes proposed for inclusion in master branch (still under review)
    2021-05-14: all codes proposed for inclusion have finished review
    where "in master" for use would mean "added to the ET's master thornlist so that it is checked out".
    the paper is the one describing the original POWER algorithm. The one in hiere is a bit different to try and be more robust and more generically applicable to simulations. It should (famous last words) still reproduce the results in the paper.
    mbabiuc
    @mbabiuc
    @rhaas80 Thank you for the info!
    mbabiuc
    @mbabiuc
    @rhaas80 Just a quick question: do the ETK thorns GRHydro and EOS_Omni accept LORENE hybrid (not tabulated) EOS?
    mbabiuc
    @mbabiuc
    Or, asked another way, I know I need Parma's version of Meudon_Bin_NS, but can I keep the ETK thorns GRHydro and EOS_Omni?
    Roland Haas
    @rhaas80
    We incorporated Parma's bugfixes in git hash 5524cad "fix handling of piecewise polytrope EOS" of ExternalLibraries-LORENE
    mbabiuc
    @mbabiuc
    Great! Thanks!
    Erik Schnetter
    @eschnett
    @rhaas80 I'm looking at line 205 of schedule.cxx in the eschnett/cuda branch. (i merged the master branch.) i think the condition there is inverted:
    (fbx.type(d) == amrex::IndexType::CELL
    i think the point should be added for vertex-centred grids, not for cell-centred grids. can you confirm my logic?
    Roland Haas
    @rhaas80
    yes, I agree. That logic is inverted.
    Erik Schnetter
    @eschnett
    @rhaas80 no it isn't... we want to calculate vertex centred quantities (since that is stored in cGH), so we inquire what we get from amrex, and correct if we get cell centred data.
    Roland Haas
    @rhaas80
    uh, so the code was right after all? Just a somewhat misleading comment?
    Erik Schnetter
    @eschnett
    maybe. i think so. still getting nans either way.
    Roland Haas
    @rhaas80
    I had a change to how tmax is computed. There is a commit message with tmax in the name. I would try and take a look.