Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

add gradient variable type parameter to AbstractEquationsParabolic #1409

Conversation

jlchan
Copy link
Contributor

@jlchan jlchan commented Apr 25, 2023

This PR modifies AbstractEquationsParabolic{NDIMS, NVARS} to AbstractEquationsParabolic{NDIMS, NVARS, GradientVariable} so that one can dispatch on (for example) an abstract parabolic equation which uses entropy variable gradients.

Another way to do this would be to introduce a trait system, similar to has_nonconservative_terms, but I think that is more complex than it needs to be.

@jlchan jlchan marked this pull request as draft April 25, 2023 18:57
@jlchan jlchan marked this pull request as ready for review April 26, 2023 02:22
Copy link
Member

@ranocha ranocha left a comment

Choose a reason for hiding this comment

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

Thanks! Which use case do you have in mind that requires this change?

# the gradient with respect to a different set of variables; see, for example, the implementation of
# [`CompressibleNavierStokesDiffusion2D`](@ref), which can utilize either "primitive" or "entropy" variables.

struct ConstantAnisotropicDiffusion2D{E, T} <: Trixi.AbstractEquationsParabolic{2, 1, GradientVariablesConservative}
Copy link
Member

Choose a reason for hiding this comment

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

Can we find a way to make this choice automatic? Otherwise, it will be a breaking change.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

As far as I know, no, since I think it would require the ability to set "default" parameters. https://discourse.julialang.org/t/type-parameters-by-default/45577

I can hold off on this PR until we are ready for a breaking release. The stuff that would require this is an optimization, and doesn't prevent me from implementing other features.

src/equations/equations.jl Outdated Show resolved Hide resolved
@jlchan
Copy link
Contributor Author

jlchan commented Apr 26, 2023

The use case would be for flux differencing schemes, where the projected entropy variables are computed as part of the inviscid scheme. Adding a GradientVariables parameter would enable dispatch on GradientVariablesEntropy for DGMultiFluxDiff schemes to avoid recomputing the entropy variable projection a second time.

src/equations/equations_parabolic.jl Outdated Show resolved Hide resolved
src/equations/equations_parabolic.jl Outdated Show resolved Hide resolved
@sloede
Copy link
Member

sloede commented Apr 26, 2023

The use case would be for flux differencing schemes, where the projected entropy variables are computed as part of the inviscid scheme. Adding a GradientVariables parameter would enable dispatch on GradientVariablesEntropy for DGMultiFluxDiff schemes to avoid recomputing the entropy variable projection a second time.

We discussed this in yesterday's meeting. We weren't sure whether there would be another option that does not introduce a new type parameter that will allow Jesse to use the same dispatch (e.g., by adding additional arguments to function calls for dispatch, or type traits, or...) but without making the type system more complicated.

We thus figured it would be the easiest if we see a PR and then can possible iterate on it and discuss alternatives.

@ranocha
Copy link
Member

ranocha commented Apr 26, 2023

The use case would be for flux differencing schemes, where the projected entropy variables are computed as part of the inviscid scheme. Adding a GradientVariables parameter would enable dispatch on GradientVariablesEntropy for DGMultiFluxDiff schemes to avoid recomputing the entropy variable projection a second time.

We discussed this in yesterday's meeting. We weren't sure whether there would be another option that does not introduce a new type parameter that will allow Jesse to use the same dispatch (e.g., by adding additional arguments to function calls for dispatch, or type traits, or...) but without making the type system more complicated.

We thus figured it would be the easiest if we see a PR and then can possible iterate on it and discuss alternatives.

I see, thanks! I'm fine with this but we may wait a little bit to see whether there are other breaking changes we would like to introduce in the near future.

@sloede
Copy link
Member

sloede commented Apr 26, 2023

The use case would be for flux differencing schemes, where the projected entropy variables are computed as part of the inviscid scheme. Adding a GradientVariables parameter would enable dispatch on GradientVariablesEntropy for DGMultiFluxDiff schemes to avoid recomputing the entropy variable projection a second time.

We discussed this in yesterday's meeting. We weren't sure whether there would be another option that does not introduce a new type parameter that will allow Jesse to use the same dispatch (e.g., by adding additional arguments to function calls for dispatch, or type traits, or...) but without making the type system more complicated.
We thus figured it would be the easiest if we see a PR and then can possible iterate on it and discuss alternatives.

I see, thanks! I'm fine with this but we may wait a little bit to see whether there are other breaking changes we would like to introduce in the near future.

Just so I understand it right: It is a breaking change, because we add a type parameter to the AbstractEquationsParabolic type and there's no way in Julia to set a default such that existing user code would continue to work without modifications?

@jlchan
Copy link
Contributor Author

jlchan commented Apr 26, 2023

That's correct. We don't technically export, AbstractParabolicEquations, but it does show up in the literate docs, so it is in some sense "public".

@ranocha
Copy link
Member

ranocha commented Apr 26, 2023

Yes, that's my point of view. We describe it in the docs, so it's stable API. This PR breaks the way how we tell people to set up their own parabolic systems, so we need to make a breaking release.

@codecov
Copy link

codecov bot commented May 2, 2023

Codecov Report

All modified and coverable lines are covered by tests ✅

Comparison is base (c79fa43) 72.65% compared to head (f9930de) 80.79%.
Report is 1 commits behind head on main.

Additional details and impacted files
@@            Coverage Diff             @@
##             main    #1409      +/-   ##
==========================================
+ Coverage   72.65%   80.79%   +8.14%     
==========================================
  Files         431      431              
  Lines       34637    34645       +8     
==========================================
+ Hits        25164    27991    +2827     
+ Misses       9473     6654    -2819     
Flag Coverage Δ
unittests 80.79% <ø> (+8.14%) ⬆️

Flags with carried forward coverage won't be shown. Click here to find out more.

Files Coverage Δ
src/Trixi.jl 43.48% <ø> (ø)
src/equations/compressible_navier_stokes_1d.jl 0.00% <ø> (ø)
src/equations/compressible_navier_stokes_2d.jl 41.67% <ø> (ø)
src/equations/compressible_navier_stokes_3d.jl 0.00% <ø> (ø)
src/equations/equations.jl 98.00% <ø> (+8.00%) ⬆️
src/equations/equations_parabolic.jl 100.00% <ø> (ø)

... and 70 files with indirect coverage changes

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

Copy link
Member

@andrewwinters5000 andrewwinters5000 left a comment

Choose a reason for hiding this comment

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

I just left two questions (in a single comment) for clarification. If this is to be a breaking change it is not time pertinent (I think).

@@ -78,7 +78,7 @@ w_2 = \frac{\rho v_1}{p},\, w_3 = \frac{\rho v_2}{p},\, w_4 = \frac{\rho v_3}{p}
"""
struct CompressibleNavierStokesDiffusion3D{GradientVariables, RealT <: Real,
E <: AbstractCompressibleEulerEquations{3}} <:
AbstractCompressibleNavierStokesDiffusion{3, 5}
AbstractCompressibleNavierStokesDiffusion{3, 5, GradientVariables}
Copy link
Member

Choose a reason for hiding this comment

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

So if I understand correctly, this modification sets GradientVariablesConservative to be the default within equations_parabolic.jl only for the Laplace diffusion whereas for Navier-Stokes we still need to pass whichever gradient_variables we want into the constructor?

For completeness, would it be necessary to add an appropriate convert_derivative_to_primitive function for the GradientVariablesConservative in the Navier-Stokes file?

Copy link
Contributor Author

@jlchan jlchan Nov 6, 2023

Choose a reason for hiding this comment

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

No, for Navier-Stokes the constructor defaults to GradientVariablesPrimitive.

https://github.com/jlchan/Trixi.jl/blob/c3ffffe0090a0913edc6e7829686b7a77a8d5bc0/src/equations/compressible_navier_stokes_2d.jl#L104-L106

I don't think we plan on adding conservative gradient variables, so I'd lean towards not implementing convert_derivative_to_primitive for conservative gradient variables.

Copy link
Member

@ranocha ranocha left a comment

Choose a reason for hiding this comment

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

Thanks! This should be ready to go, isn't it, @jlchan ?

@ranocha ranocha changed the base branch from main to v0.6-dev November 7, 2023 06:12
Copy link
Member

@ranocha ranocha left a comment

Choose a reason for hiding this comment

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

Wait, sorry, I forgot something - could you please add a NEWS.md entry?
I also changed the base of the PR to the v0.6 development branch @sloede created.

@jlchan
Copy link
Contributor Author

jlchan commented Nov 7, 2023

Thanks! And yes, I'll add this to NEWS.md

@jlchan jlchan requested a review from ranocha November 7, 2023 14:34
@jlchan
Copy link
Contributor Author

jlchan commented Nov 8, 2023

Merging as per comments on Slack.

@jlchan jlchan merged commit 32c787d into trixi-framework:v0.6-dev Nov 8, 2023
26 of 29 checks passed
@sloede sloede mentioned this pull request Nov 9, 2023
2 tasks
ranocha pushed a commit that referenced this pull request Nov 10, 2023
…1409)

* add gradient variable type parameter

* fix parabolic literate test

* remove trailing comment

* remove unnecessary abstract type

* move gradient variable structs

* formatting

* fix dropped changes

* try to fix doc tests

* fixing navier stokes 1D

* formatting

* remove duplicate GradientVariablesPrimitive/Entropy definition

* update news
@ranocha ranocha mentioned this pull request Nov 10, 2023
8 tasks
ranocha added a commit that referenced this pull request Nov 10, 2023
* Breaking changes HLL MHD

* format

* format examples

* hlle

* fix

* news, tests, example changes

* fmt

* remove left-right-biased flux from test

* Set version to v0.6.0

* Migrate neural network-based indicators to new repository (#1701)

* Remove all neural network indicator stuff from `src/`

* Migrate neural network tests

* Migrate neural network examples

* Migrate test dependencies

* Update NEWS.md

* Fix typo

* Remove Requires.jl-based use of Flux.jl

* Fix formatting

* Add migration of indicators to section with breaking changes

---------

Co-authored-by: Hendrik Ranocha <[email protected]>

* fix hlle noncartesian 2d

* remove parantheses

* correct test vals

* Make parabolic terms nonexperimental (#1714)

* Make parabolic terms non-experimental

* Make NSE a separate item

* Add MPI to supported features

* Mention that parabolic terms are now officially supported in NEWS.md

Co-authored-by: Hendrik Ranocha <[email protected]>

* Deprecate some `DGMultiMesh` constructors  (#1709)

* remove previously deprecated functions

* fix typo in NEWS.md about deprecation vs removal

* fix literate tutorial

* removing other deprecation

* format

* Revert "fix typo in NEWS.md about deprecation vs removal"

This reverts commit 6b03020.

* add gradient variable type parameter to `AbstractEquationsParabolic` (#1409)

* add gradient variable type parameter

* fix parabolic literate test

* remove trailing comment

* remove unnecessary abstract type

* move gradient variable structs

* formatting

* fix dropped changes

* try to fix doc tests

* fixing navier stokes 1D

* formatting

* remove duplicate GradientVariablesPrimitive/Entropy definition

* update news

* bring downloads back

* fix failing test

* fmt

---------

Co-authored-by: Michael Schlottke-Lakemper <[email protected]>
Co-authored-by: Hendrik Ranocha <[email protected]>
ranocha pushed a commit that referenced this pull request Nov 11, 2023
…1409)

* add gradient variable type parameter

* fix parabolic literate test

* remove trailing comment

* remove unnecessary abstract type

* move gradient variable structs

* formatting

* fix dropped changes

* try to fix doc tests

* fixing navier stokes 1D

* formatting

* remove duplicate GradientVariablesPrimitive/Entropy definition

* update news
ranocha added a commit that referenced this pull request Nov 11, 2023
* Breaking changes HLL MHD

* format

* format examples

* hlle

* fix

* news, tests, example changes

* fmt

* remove left-right-biased flux from test

* Set version to v0.6.0

* Migrate neural network-based indicators to new repository (#1701)

* Remove all neural network indicator stuff from `src/`

* Migrate neural network tests

* Migrate neural network examples

* Migrate test dependencies

* Update NEWS.md

* Fix typo

* Remove Requires.jl-based use of Flux.jl

* Fix formatting

* Add migration of indicators to section with breaking changes

---------

Co-authored-by: Hendrik Ranocha <[email protected]>

* fix hlle noncartesian 2d

* remove parantheses

* correct test vals

* Make parabolic terms nonexperimental (#1714)

* Make parabolic terms non-experimental

* Make NSE a separate item

* Add MPI to supported features

* Mention that parabolic terms are now officially supported in NEWS.md

Co-authored-by: Hendrik Ranocha <[email protected]>

* Deprecate some `DGMultiMesh` constructors  (#1709)

* remove previously deprecated functions

* fix typo in NEWS.md about deprecation vs removal

* fix literate tutorial

* removing other deprecation

* format

* Revert "fix typo in NEWS.md about deprecation vs removal"

This reverts commit 6b03020.

* add gradient variable type parameter to `AbstractEquationsParabolic` (#1409)

* add gradient variable type parameter

* fix parabolic literate test

* remove trailing comment

* remove unnecessary abstract type

* move gradient variable structs

* formatting

* fix dropped changes

* try to fix doc tests

* fixing navier stokes 1D

* formatting

* remove duplicate GradientVariablesPrimitive/Entropy definition

* update news

* bring downloads back

* fix failing test

* fmt

---------

Co-authored-by: Michael Schlottke-Lakemper <[email protected]>
Co-authored-by: Hendrik Ranocha <[email protected]>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants