Skip to content
GitLab
Projects Groups Snippets
  • /
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
    • Contribute to GitLab
  • Sign in
  • SWIFTsim SWIFTsim
  • Project information
    • Project information
    • Activity
    • Labels
    • Members
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributors
    • Graph
    • Compare
  • Issues 57
    • Issues 57
    • List
    • Boards
    • Service Desk
    • Milestones
  • Merge requests 21
    • Merge requests 21
  • Deployments
    • Deployments
    • Releases
  • Monitor
    • Monitor
    • Incidents
  • Analytics
    • Analytics
    • Value stream
    • Repository
  • Wiki
    • Wiki
  • Snippets
    • Snippets
  • Activity
  • Graph
  • Create a new issue
  • Commits
  • Issue Boards
Collapse sidebar
  • SWIFT
  • SWIFTsimSWIFTsim
  • Merge requests
  • !275

New h max definition

  • Review changes

  • Download
  • Email patches
  • Plain diff
Merged Matthieu Schaller requested to merge new_h_max_definition into master Oct 27, 2016
  • Overview 14
  • Commits 9
  • Changes 33

Since h_max was always an annoyance, here is a better definition.

There is a new parameter now called max_top_level_cells that allows you to set the (cube root of the) maximal number of top-level cells you want. So instead of referring to it as a maximal smoothing length you directly give the number of cells. Of course if the physics requires larger cells, the parameter is ignored. This default to 12 if unspecified, giving 1728 top-level cells.

The only reason you would want more top-level cells is for simulations on large systems to obtain a finer MPI decomposition.

I also force a rebuild after time-step 0 now to make sure we have good grid and set of tasks even if the original mesh was based on garbage smoothing lengths values entered by the user.

What do you think ?

Assignee
Assign to
Reviewers
Request review from
Time tracking
Source branch: new_h_max_definition