BugFix Temperature units in disk

[adamdempsey90]

Background

• Add the correct kb/mu factors to the disk temperature profile.
• Allow constant viscosity
• Force -O3 in RelWithDebInfo builds

Closes #53
Closes #54

Description of Changes

Checklist

• New features are documented
• Tests added for bug fixes and new features
• (@lanl.gov employees) Update copyright on changed files

[adamdempsey90]

Note also that for the cooling package, you have to include the correct kb/mu in you input file if you previously defined it as P/rho

[pdmullen]

Is -O3 always safe? I wonder if there is a good reason why parth doesn't use it by default for release. Maybe it is they avoid it due to extended compile times and/or memory useage?

[shengtai]

I agree that “disk.hpp” pgen should be scale-free, even with user-input cgs-unit conversion. From: Patrick Mullen ***@***.***> Reply-To: lanl/artemis ***@***.***> Date: Thursday, February 6, 2025 at 3:17 PM To: lanl/artemis ***@***.***> Cc: "Li, Shengtai" ***@***.***>, Review requested ***@***.***> Subject: [EXTERNAL] Re: [lanl/artemis] BugFix Temperature units in disk (PR #55) @pdmullen approved this pull request.

________________________________ In src/pgen/disk.hpp<https://urldefense.com/v3/__https:/github.com/lanl/artemis/pull/55*discussion_r1945546781__;Iw!!Bt8fGhp8LhKGRg!GB2gXrW2KFBi-83WTXkJsVAe4N1Fvr47KOL4JcDvzqMLXoCX2AqBYVwj7QoiaekDLqSSpoU-VWdQvYRWX7LWkA$>:

@@ -275,6 +278,9 @@ inline void InitDiskParams(MeshBlock *pmb, ParameterInput *pin) {

disk_params.l0 = pin->GetOrAddReal("problem", "l0", 0.0); disk_params.dust_to_gas = pin->GetOrAddReal("problem", "dust_to_gas", 0.01); disk_params.temp_soft2 = pin->GetOrAddReal("problem", "temp_soft", 0.0); + const auto mu = gas_pkg->Param<Real>("mu"); + auto &constants = artemis_pkg->Param<ArtemisUtils::Constants>("constants"); + disk_params.kbmu = constants.GetKBCode() / (mu * constants.GetAMUCode()); Can we rename this to indicate that it also includes a factor of amu? I usually think of mu itself as being dimensionless.

________________________________ In src/pgen/disk.hpp<https://urldefense.com/v3/__https:/github.com/lanl/artemis/pull/55*discussion_r1945549632__;Iw!!Bt8fGhp8LhKGRg!GB2gXrW2KFBi-83WTXkJsVAe4N1Fvr47KOL4JcDvzqMLXoCX2AqBYVwj7QoiaekDLqSSpoU-VWdQvYSZVBLhDA$>:

@@ -101,7 +103,8 @@ Real TempProfile(struct DiskParams pgen, const Real R, const Real z) {

const Real H = R * pgen.h0 * std::pow(R / pgen.r0, pgen.flare); const Real ir1 = 1.0 / std::sqrt(R * R + pgen.temp_soft2); const Real omk2 = SQR(pgen.Omega0) * ir1 * ir1 * ir1; - const Real T0 = omk2 * H * H / pgen.Gamma; + // c_iso^2 = P/rho = kb/mu T = Omk^2 H^2 + const Real T0 = omk2 * H * H / (pgen.kbmu * pgen.Gamma); I trust that you implemented this correctly... but just for my own understanding: Could we have equivalently kept everything (mostly) as was, working in this pgen in a "scale free capacity"... then only at the end introduce a conversion to cgs, then to artemis code units, then doing v(b, gas::prim::density(), k, j, i) = gdens * unit_conv; v(b, gas::prim::sie(), k, j, i) = gsie * unit_conv; This is just me trying to forward think about how people will interface with our units infrastructure and some potential pitfalls.

________________________________ In CMakeLists.txt<https://urldefense.com/v3/__https:/github.com/lanl/artemis/pull/55*discussion_r1945552088__;Iw!!Bt8fGhp8LhKGRg!GB2gXrW2KFBi-83WTXkJsVAe4N1Fvr47KOL4JcDvzqMLXoCX2AqBYVwj7QoiaekDLqSSpoU-VWdQvYTPg2EuRQ$>:

@@ -25,6 +25,10 @@ option(ARTEMIS_ENABLE_OPENMP "Enable OpenMP for artemis and parthenon" OFF)

option(ARTEMIS_ENABLE_COMPILE_TIMING "Enable timing of compilation of artemis" ON) option(ARTEMIS_ENABLE_ASAN "Enable AddressSanitizer to detect memory errors" OFF) +# Force -03 optimization for RelWithDebInfo +set(CMAKE_CXX_FLAGS_RELWITHDEBINFO "-O3 -g -DNDEBUG" CACHE STRING "Force -O3 in RelWithDebInfo mode" FORCE) Is -O3 always safe? I wonder if there is a good reason why parth doesn't use it by default for release. Maybe it is they avoid it due to extended compile times and/or memory useage? — Reply to this email directly, view it on GitHub<https://urldefense.com/v3/__https:/github.com/lanl/artemis/pull/55*pullrequestreview-2600116680__;Iw!!Bt8fGhp8LhKGRg!GB2gXrW2KFBi-83WTXkJsVAe4N1Fvr47KOL4JcDvzqMLXoCX2AqBYVwj7QoiaekDLqSSpoU-VWdQvYQESOmEmQ$>, or unsubscribe<https://urldefense.com/v3/__https:/github.com/notifications/unsubscribe-auth/AHF3ZGY65QU6ABC2XR6YJRL2OPNQFAVCNFSM6AAAAABWUBUAI6VHI2DSMVQWIX3LMV43YUDVNRWFEZLROVSXG5CSMV3GSZLXHMZDMMBQGEYTMNRYGA__;!!Bt8fGhp8LhKGRg!GB2gXrW2KFBi-83WTXkJsVAe4N1Fvr47KOL4JcDvzqMLXoCX2AqBYVwj7QoiaekDLqSSpoU-VWdQvYToviFrfA$>. You are receiving this because your review was requested.Message ID: ***@***.***>