Skip to content

Viscosity for multispec DG#707

Open
samuelh-nd wants to merge 16 commits into
developfrom
viscosity_Suther_1
Open

Viscosity for multispec DG#707
samuelh-nd wants to merge 16 commits into
developfrom
viscosity_Suther_1

Conversation

@samuelh-nd
Copy link
Copy Markdown

@samuelh-nd samuelh-nd commented May 7, 2026

This new branch combines the viscosity_1 and viscosity_Suther branches to implement viscosity for multispecies DG. Constant viscosity is currently running and quantitative validation is ongoing. Sutherland's Law validation is coming soon. Please use this viscosity_Suther_1 branch for all viscosity development going forward.


This change is Reviewable

@adityakpandare adityakpandare removed the request for review from jiajiaecho May 7, 2026 20:24
Copy link
Copy Markdown
Member

@adityakpandare adityakpandare left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thank you for the contributions. This is quite a large change-set. Due to that it is unrealistic to look at all of it at once. My suggestion is that we do this code-review step-wise:

  1. parsing,
  2. wiring into DG,
  3. viscous flux operators,
  4. viscosity (Sutherland's law) or material EOS related changes.

I have taken a look at the first item from this list, and have comments below. Once those are addressed, we can move to the next items in the list.

A couple of additional things: our CI servers are failing on this branch. Passing all builds (except the gnu-smp one) is another criterion we require for feature branches to be merged in, so that users do not get adversely affected. Secondly, our styling guidelines are found here: https://quinoacomputing.github.io/contributing.html#styling. Please go through these, and check that those are followed in your change-set. From what I can see, there are quite a few trailing whitespaces in this change-set.

Please let me know if you have any questions.

@adityakpandare reviewed 6 files and made 12 comments.
Reviewable status: 6 of 27 files reviewed, 11 unresolved discussions (waiting on madpeck3 and samuelh-nd).


src/Control/Inciter/InputDeck/InputDeck.hpp line 146 at r1 (raw file):

  tag::Sutherland, std::vector< bool >,
  tag::id,        std::vector< uint64_t >,
  tag::gamma,     std::vector< tk::real >,

Lot of repeating quantities here. Let's clean this up to remove repeats.


src/Control/Inciter/InputDeck/LuaParser.hpp line 40 at r1 (raw file):

      ctr::InputDeck& gideck );

    //! Check and store material property into inpudeck storage

This function description is the same as the checkStoreMatProp(). Let's modify it to say what it really does.


src/Control/Inciter/InputDeck/LuaParser.cpp line 638 at r1 (raw file):

            mati_deck.get< tag::mu >());   
        }
      }

I don't understand where this code is coming from. It looks like a duplicate of what's in registerMaterials(). It might be that your recent merge with develop was incorrect.


src/Control/Inciter/InputDeck/LuaParser.cpp line 1421 at r1 (raw file):

  if (gideck.get< tag::pde >() != inciter::ctr::PDEType::MULTIMAT &&
      gideck.get< tag::pde >() != inciter::ctr::PDEType::COMPFLOW) return;

Unnecessary line removal


src/Control/Inciter/InputDeck/LuaParser.cpp line 1796 at r1 (raw file):

    else gideck.get< tag::multispecies, tag::viscous >() = true;
      checkStoreMatProp(sol_mat[imat+1], "mu", ntype, mati_deck.get< tag::mu >());
    }

Same thing about code here. This code belongs in registerSpecies(). Can you please check if your recent merge with develop caused this?


src/Control/Inciter/InputDeck/LuaParser.cpp line 1830 at r1 (raw file):

  // set target data in inputdeck
  // species vector size is one, since all species are only of one type for now
  gideck.get< tag::species >().resize(1);

This resize is already done a few lines above. Let's remove it.


src/Control/Inciter/InputDeck/LuaParser.cpp line 1930 at r1 (raw file):

        // Sutherland (bool)
        checkStoreMatPropBool(sol_spc[imat+1], "Sutherland", nspec,
          spci_deck.get< tag::Sutherland >());

Why do we need a vector for checking if Sutherland's law is used or not? Is there a situation where we would use Sutherland's law for some species, and not use it for others?


src/Control/Inciter/InputDeck/LuaParser.cpp line 1931 at r1 (raw file):

        checkStoreMatPropBool(sol_spc[imat+1], "Sutherland", nspec,
          spci_deck.get< tag::Sutherland >());
      }

I don't think these changes should be in the else-branch here. This basically means that if a spec_name is provided, viscosity cannot be triggered, which is not intended. Let's move these outside that if-test.


src/Control/Inciter/InputDeck/LuaParser.cpp line 1972 at r1 (raw file):

  std::vector< bool >& storage )
// *****************************************************************************
//  Check and store material property into inpudeck storage

Let's change this comment to describe what this function does- current description is same are checkstorematprop().


src/PDE/MultiMat/DGMultiMat.hpp line 991 at r1 (raw file):

        tk::volInt( nmat, t, m_mat_blk, ndof, rdof, nelem,
        inpoel, coord, geoElem, flux, visc_flux, velfn, Problem::src, U, P, ndofel, R, viscous,
                    intsharp);

The changes above to the indentation etc are unnecessary. Let's adhere to the styling that's present and leave the diff to be minimal.


src/PDE/Transport/DGTransport.hpp line 406 at r1 (raw file):

          std::get<0>(b), fd, geoFace, geoElem, inpoel, coord, t, Upwind::flux,
          visc_flux, Problem::prescribedVelocity, std::get<1>(b), U, P, ndofel, R,
          riemannDeriv, viscous, intsharp );

Please check for unnecessary indentation changes here as well. Let's keep the diff to a minimal, especially considering how big a change-set this is.

@adityakpandare adityakpandare mentioned this pull request May 11, 2026
Copy link
Copy Markdown
Author

@samuelh-nd samuelh-nd left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for your feedback. I've left a few comments regarding parsing - future commits will remove duplicate code and simplify the control file. I'm currently working on revisions to ensure this branch passes all required CI server builds.

Contributions going forward will adhere to styling.

@samuelh-nd made 5 comments.
Reviewable status: 6 of 27 files reviewed, 11 unresolved discussions (waiting on adityakpandare and madpeck3).


src/Control/Inciter/InputDeck/LuaParser.cpp line 638 at r1 (raw file):

Previously, adityakpandare (Aditya Pandare) wrote…

I don't understand where this code is coming from. It looks like a duplicate of what's in registerMaterials(). It might be that your recent merge with develop was incorrect.

Yes, this section of code came from my recent merge with develop.

The registerMaterials() method only parses the control file when the if statement at line 1602 is returned True. It is returned False for the cases I run because I use the MultiSpecies PDEType, not MultiMat or CompFlow. I left these duplicate calls to checkStoreMatProp() instead of editing registerMaterials().

See my comments for line 1796 on using a "mu" keyword in the material block. I will remove this duplicate code and use only the species block for specifying viscosity parameters.


src/Control/Inciter/InputDeck/LuaParser.cpp line 1796 at r1 (raw file):

Previously, adityakpandare (Aditya Pandare) wrote…

Same thing about code here. This code belongs in registerSpecies(). Can you please check if your recent merge with develop caused this?

The intention of this addition was to read the value of "mu" in the control file's material block (like the Stiffened-gas EoS), hence its placement in registerMaterials(). I see now that for the TPG EoS, mixture viscosity is calculated only by referencing the species block. So I agree that this code is unnecessary. Moving forward I will remove the "mu" keyword in the material block and only require viscosity parameters in the species block.


src/Control/Inciter/InputDeck/LuaParser.cpp line 1930 at r1 (raw file):

Previously, adityakpandare (Aditya Pandare) wrote…

Why do we need a vector for checking if Sutherland's law is used or not? Is there a situation where we would use Sutherland's law for some species, and not use it for others?

The intention here was to have the option to use constant viscosity (Sutherland = {false}) or Sutherland's Law (Sutherland = {true}). I don't see a reason to specify this for each species, so I propose moving this boolean check to the multispecies block of the control file.


src/Control/Inciter/InputDeck/LuaParser.cpp line 1931 at r1 (raw file):

Previously, adityakpandare (Aditya Pandare) wrote…

I don't think these changes should be in the else-branch here. This basically means that if a spec_name is provided, viscosity cannot be triggered, which is not intended. Let's move these outside that if-test.

I see - agreed.

Copy link
Copy Markdown
Author

@samuelh-nd samuelh-nd left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@samuelh-nd made 7 comments.
Reviewable status: 6 of 27 files reviewed, 11 unresolved discussions (waiting on adityakpandare and madpeck3).


src/Control/Inciter/InputDeck/InputDeck.hpp line 146 at r1 (raw file):

Previously, adityakpandare (Aditya Pandare) wrote…

Lot of repeating quantities here. Let's clean this up to remove repeats.

Done.


src/Control/Inciter/InputDeck/LuaParser.hpp line 40 at r1 (raw file):

Previously, adityakpandare (Aditya Pandare) wrote…

This function description is the same as the checkStoreMatProp(). Let's modify it to say what it really does.

Done.


src/Control/Inciter/InputDeck/LuaParser.cpp line 1421 at r1 (raw file):

Previously, adityakpandare (Aditya Pandare) wrote…

Unnecessary line removal

Done.


src/Control/Inciter/InputDeck/LuaParser.cpp line 1830 at r1 (raw file):

Previously, adityakpandare (Aditya Pandare) wrote…

This resize is already done a few lines above. Let's remove it.

Done.


src/Control/Inciter/InputDeck/LuaParser.cpp line 1972 at r1 (raw file):

Previously, adityakpandare (Aditya Pandare) wrote…

Let's change this comment to describe what this function does- current description is same are checkstorematprop().

Done.


src/PDE/MultiMat/DGMultiMat.hpp line 991 at r1 (raw file):

Previously, adityakpandare (Aditya Pandare) wrote…

The changes above to the indentation etc are unnecessary. Let's adhere to the styling that's present and leave the diff to be minimal.

Done.


src/PDE/Transport/DGTransport.hpp line 406 at r1 (raw file):

Previously, adityakpandare (Aditya Pandare) wrote…

Please check for unnecessary indentation changes here as well. Let's keep the diff to a minimal, especially considering how big a change-set this is.

Done.

Copy link
Copy Markdown
Member

@adityakpandare adityakpandare left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@samuelh-nd, thank you for your hard work on this. We are almost at the end of bullet-1 from the list above. I have a couple of minor comments. Once those are resolved, I can begin reviewing bullet-2. Thank you again!

@adityakpandare reviewed 7 files and all commit messages, made 9 comments, and resolved 11 discussions.
Reviewable status: 8 of 27 files reviewed, 5 unresolved discussions (waiting on madpeck3 and samuelh-nd).


src/Control/Inciter/InputDeck/LuaParser.cpp line 638 at r1 (raw file):

Previously, samuelh-nd (Samuel Harder) wrote…

Yes, this section of code came from my recent merge with develop.

The registerMaterials() method only parses the control file when the if statement at line 1602 is returned True. It is returned False for the cases I run because I use the MultiSpecies PDEType, not MultiMat or CompFlow. I left these duplicate calls to checkStoreMatProp() instead of editing registerMaterials().

See my comments for line 1796 on using a "mu" keyword in the material block. I will remove this duplicate code and use only the species block for specifying viscosity parameters.

Thanks for fixing this.


src/Control/Inciter/InputDeck/LuaParser.cpp line 1796 at r1 (raw file):

Previously, samuelh-nd (Samuel Harder) wrote…

The intention of this addition was to read the value of "mu" in the control file's material block (like the Stiffened-gas EoS), hence its placement in registerMaterials(). I see now that for the TPG EoS, mixture viscosity is calculated only by referencing the species block. So I agree that this code is unnecessary. Moving forward I will remove the "mu" keyword in the material block and only require viscosity parameters in the species block.

Thanks!


src/Control/Inciter/InputDeck/InputDeck.hpp line 147 at r2 (raw file):

  tag::temp_ref,  std::vector< tk::real >,
  tag::mu_ref,    std::vector< tk::real >,
  tag::C,         std::vector< tk::real >

Let's add documentation of these 4 new keywords (scroll below in this file to find this). Easy way to do this is looking up keywords.insert({"spec_name".... and add similar docs for the 4 new keywords. We typically include the following info in the documentation: which PDE (here multispecies), what are the defaults, what are the units (we always use SI units in Quinoa).


src/Control/Inciter/InputDeck/LuaParser.cpp line 379 at r2 (raw file):

    storeIfSpecd< bool >(lua_ideck["multispecies"], "Sutherland",
      gideck.get< tag::multispecies, tag::Sutherland >(),
      false);

Thanks for adding these defaults!


src/Control/Inciter/InputDeck/LuaParser.cpp line 1683 at r2 (raw file):

      std::vector< std::string >(nspec, ""));
    // If viscous problem, read all parameters from control file
    if (gideck.get< tag::multispecies, tag::viscous >()){

Putting the viscosity-related parsing here would mean that those parameters are only read-in for the TPG species. Do we intend to use viscosity for CPG (stiffened-gas)? If yes, we will have to duplicate this code in the stiffened-gas if-branch above.


src/Control/Inciter/InputDeck/LuaParser.cpp line 1686 at r2 (raw file):

      // mu_ref (Sutherland)
      checkStoreMatProp(sol_spc[imat+1], "mu_ref", nspec,
        spci_deck.get< tag::mu_ref >());

In a typical multi-species setup, do each species have different mu_ref, C? If not, this should be moved to the multispecies block parsing.


src/PDE/MultiMat/DGMultiMat.hpp line 1609 at r2 (raw file):

              [[maybe_unused]] const std::vector< EOS >& mat_blk,
              [[maybe_unused]] const std::vector< tk::real >& ugp,
              [[maybe_unused]] const std::vector< std::array< tk::real, 3 > > & grad_all )

Let's remove var-names that are unused rather than adding the [[maybe_unused]] attribute. So, for example [[maybe_unused]] const std::vector< tk::real >& ugp would simply become [[maybe_unused]] const std::vector< tk::real >&.


src/PDE/Transport/DGTransport.hpp line 701 at r2 (raw file):

              [[maybe_unused]] const std::vector< EOS >& mat_blk,
              [[maybe_unused]] const std::vector< tk::real >& ugp,
              [[maybe_unused]] const std::vector< std::array< tk::real, 3 > > & grad_all )

Same here, let's remove the maybe_unused attr, and remove the arg-names.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants