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

Some initial refactoring #122

Merged
merged 15 commits into from
Feb 26, 2024
Merged

Some initial refactoring #122

merged 15 commits into from
Feb 26, 2024

Conversation

archermarx
Copy link
Collaborator

@archermarx archermarx commented Feb 23, 2024

Addresses #121 in part, as well as making some other changes to the internals.
The main goal of this is to remove the vestiges of DifferentialEquations.jl. Previously, we had used that library for timestepping, and the entire design of the code was based on that. However, that led to some awkward design choices. Now that we no longer use DifferentialEquations, I would like to restructure the code in a way that makes more sense. This PR is a draft for now.

What's changed

  • The electron energy is no longer included in the state vector U. This saves about 3% of the computational time as we have reduced the number of rows we iterate through by 1
  • The electron pressure coupled scheme has been removed. While nice, it saw very little use and was restricted to singly-charged ions only. Including it required a lot of special-casing that made the code longer and more difficult to follow.
  • The test dependencies have been moved from test/Project.toml to the [extras] section of Project.toml. I have also pruned the test deps (removing Plots and others) so that the only heavy test dep is Symbolics, which we use for OVS.
  • Some unused arguments have been removed from the stage limiter
  • Remove the whole ODEProblem thing and associated structure
  • Remove references to DifferentialEquations from docs

Still to come (in later PRs)

  • Restructure params and cache. These were designed to work with the DifferentialEquations.jl interface, but it's difficult to see what's in there. Ideally, we'd replace with more descriptively-named structures (perhaps "simulation" and "data"?). This would be a pretty large breaking change, so perhaps we could include methods for accessing things the "old way" for a while
  • As part of the above, the Solution object could be made more useful with more descriptive fields. Having most of the important plasma properties hidden behind params.cache is not an ideal state of affairs
  • Fix restarts (maybe hold off until structure is more stable)

@codecov-commenter
Copy link

codecov-commenter commented Feb 23, 2024

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 84.11%. Comparing base (9b9247a) to head (1e2619b).

❗ Your organization needs to install the Codecov GitHub app to enable full functionality.

Additional details and impacted files

Impacted file tree graph

@@            Coverage Diff             @@
##             main     #122      +/-   ##
==========================================
- Coverage   87.22%   84.11%   -3.11%     
==========================================
  Files          36       36              
  Lines        2058     2008      -50     
==========================================
- Hits         1795     1689     -106     
- Misses        263      319      +56     
Files Coverage Δ
src/HallThruster.jl 100.00% <100.00%> (ø)
src/numerics/flux.jl 89.94% <100.00%> (-1.69%) ⬇️
src/numerics/limiters.jl 96.29% <100.00%> (+0.14%) ⬆️
src/physics/fluid.jl 100.00% <ø> (ø)
src/physics/gas.jl 100.00% <ø> (ø)
src/physics/thermal_conductivity.jl 63.63% <ø> (ø)
src/simulation/boundaryconditions.jl 100.00% <100.00%> (ø)
src/simulation/configuration.jl 78.68% <100.00%> (+0.42%) ⬆️
src/simulation/electronenergy.jl 96.59% <100.00%> (-0.04%) ⬇️
src/simulation/geometry.jl 95.58% <ø> (ø)
... and 8 more

... and 1 file with indirect coverage changes


Continue to review full report in Codecov by Sentry.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 9b9247a...1e2619b. Read the comment docs.

@archermarx archermarx self-assigned this Feb 23, 2024
@archermarx
Copy link
Collaborator Author

I'm gonna mark this ready for review. @DecBrick, could you take a look?

@archermarx archermarx marked this pull request as ready for review February 26, 2024 15:40
docs/src/run.md Outdated
@@ -136,13 +136,13 @@ tasks.

### The `Solution` object

Running a simulation returns a `HallThruster.Solution` object. This mimics a DifferentialEquations `DiffEqSolution` object and has the same fields:
Running a simulation returns a `HallThruster.Solution` object, which has the the same fields:
Copy link
Contributor

Choose a reason for hiding this comment

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

Might be missing context, but the "same fields" seems to still be vestigial.

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

Yep, it is. Fixed!

# Sound speeds
aL = sqrt((charge_factor * TeL + γ * kB * TL) / mi)
aR = sqrt((charge_factor * TeR + γ * kB * TR) / mi)
aL = sqrt((γ * kB * TL) / mi)
Copy link
Contributor

@DecBrick DecBrick Feb 26, 2024

Choose a reason for hiding this comment

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

As the ions currently only have a single temperature, is it worth leaving in the left and right calculations for if an ion temperature model is eventually implemented?

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

Yeah, that's what I'm currently thinking

@@ -14,7 +14,8 @@ function wall_power_loss(model::ConstantSheathPotential, U, params, i)
(;z_cell, index, L_ch, config, cache) = params

ne = cache.ne[i]
ϵ = U[index.nϵ, i] / ne
nϵ = cache.nϵ[i]
ϵ = nϵ / ne
Copy link
Contributor

Choose a reason for hiding this comment

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

Seems like nϵ is only called once in this file, could save an allocation unless it's a setup for future changes

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

naming a variable doesn't cause a memory allocation. we still need to compute \epsilon in order to get the wall power loss here

test/runtests.jl Outdated
@@ -80,3 +90,54 @@ end
end
end
end

Copy link
Contributor

Choose a reason for hiding this comment

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

massive comment left at the bottom

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

removed, thanks

Copy link
Contributor

@DecBrick DecBrick left a comment

Choose a reason for hiding this comment

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

Looks good so far aside from the comments above.

For future steps, with regards to the params structure, it may be good to have a method to be able to call all of its keys in a concise manner from a solution object to allow the user to be able to see what properties are saved. A native way to do this in Julia may exist, but I haven't encountered it so far.

@archermarx
Copy link
Collaborator Author

Looks good so far aside from the comments below.

For future steps, with regards to the params structure, it may be good to have a method to be able to call all of its keys in a concise manner from a solution object to allow the user to be able to see what properties are saved. A native way to do this in Julia may exist, but I haven't encountered it so far.

i think fieldnames(typeof(sol.savevals[1])) would work, but i could add a saved_properties method that does that for you

@DecBrick
Copy link
Contributor

Well it does, maybe not do a full method but make a note about that in the documentation as the documentation on what fields the object has may not always be up to date.

@archermarx
Copy link
Collaborator Author

I've added a HallThruster.saved_fields() function which will list all fields that get saved to sol.savevals. I've also updated the jupyter notebook to call this instead of using the static list of fields, and the docs so that this field is mentioned.

@archermarx archermarx merged commit df19a3f into main Feb 26, 2024
4 checks passed
@archermarx archermarx deleted the refactor-1 branch February 27, 2024 00:37
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