Skip to content

NURBSExtension Constructor and edge_to_knot mapping #4835

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

Open
wants to merge 40 commits into
base: master
Choose a base branch
from

Conversation

justinlaughlin
Copy link
Contributor

@justinlaughlin justinlaughlin commented Apr 28, 2025

Summary

This PR

  • Adds a new algorithm, Mesh::GetEdgeToUniqueKnotvector, to calculate the edge_to_knot map (now renamed edge_to_ukv, where ukv is the "unique knot vector" index) used by NURBS meshes
  • Mesh::GetEdgeToUniqueKnotvector also produces the intermediary index maps. For now the only one that is needed/returned is ukv_to_rpkv, used by the patch-based NURBSExtension constructor.
  • Updates the NURBSExtension constructor using NURBSPatch(es) and patchTopo to use Mesh::GetEdgeToUniqueKnotvector
  • Adds a new test for the NURBSExtension constructor
  • Adds a few more NURBS test meshes; miniapps/nurbs/plus-nurbs-permuted.mesh is an example mesh that would not work previously but now does.
  • Modifies the miniapps/nurbs CMakeLists so that miniapps/nurbs/meshes is copied over on builds

Background

This work began while implementing code to automatically create a low-order version of a NURBS mesh — keeping the number of DOFS and placing the new knots at e.g. Greville abscissa of the higher order mesh. The cleanest approach in my opinion is to grab the NURBSPatch(es) and patchTopo of a Mesh, make adjustments, then feed that into the new NURBSExtension constructor introduced in #4566.

Doing so, I found that we'd often get a Inconsistent edge-to-knot mapping error. The setting of edge_to_knot in the constructor was 1) not accounting for the sign-convention if (v[0] > v[1]) { edge_to_knot[j] = -1 - edge_to_knot[j]; } and 2) using the "patch knot vector index", pkv = p*dim + d (p is the patch index, dim is the total number of dimensions, and d is the local dimension index) rather than the "unique knot vector index". E.g. 3 patches in 3d joined on the same axis would have 5 "unique knot vectors", but 9 "patch knot vectors".

edge_to_knot is typically set via Mesh::LoadPatchTopo; it is either set by the edges field in a .mesh file, or it is solved for by an algorithm. This algorithm worked for the test cases miniapps/nurbs/meshes/two-cubes-nurbs-autoedge.mesh and miniapps/nurbs/meshes/two-squares-nurbs-autoedge.mesh but gave "inconsistent edge-to-knot mappings" for other meshes such as data/beam-hex-nurbs.mesh.

PR Author Editor Reviewers Assignment Approval Merge
#4835 @justinlaughlin @tzanio @dylan-copeland + @tzanio 4/30/25 6/9/25 ⌛due 5/21/25
PR Checklist
  • Code builds.
  • Code passes make style.
  • Update CHANGELOG:
    • Is this a new feature users need to be aware of? New or updated example or miniapp?
    • Does it make sense to create a new section in the CHANGELOG to group with other related features?
  • Update INSTALL:
    • Had a new optional library been added? If so, what range of versions of this library are required? (Make sure the external library is compatible with our BSD license, e.g. it is not licensed under GPL!)
    • Have the version ranges for any required or optional libraries changed?
    • Does make or cmake have a new target?
    • Did the requirements or the installation process change? (rare)
  • Update continuous integration server configurations if necessary (e.g. with new version requirements for each of MFEM's dependencies)
    • .github
    • .appveyor.yml
  • Update .gitignore:
    • Check if make distclean; git status shows any files that were generated from the source by the project (not an IDE) but we don't want to track in the repository.
    • Add new patterns (just for the new files above) and re-run the above test.
  • New examples:
    • All sample runs at the top of the example source file work.
    • Update examples/makefile:
      • Add the example code to the appropriate SEQ_EXAMPLES and PAR_EXAMPLES variables.
      • Add any files generated by it to the clean target.
      • Add the example binary and any files generated by it to the top-level .gitignore file.
    • Update examples/CMakeLists.txt:
      • Add the example code to the ALL_EXE_SRCS variable.
      • Make sure THIS_TEST_OPTIONS is set correctly for the new example.
    • List the new example in doc/CodeDocumentation.dox.
    • If new examples directory (e.g.examples/pumi), list it in doc/CodeDocumentation.conf.in
    • Companion pull request for documentation in mfem/web repo:
      • Update or add example-specific documentation, see e.g. the src/examples.md.
      • Add the description, labels and screenshots in src/examples.md and src/img.
      • In examples.md, list the example under the appropriate categories, add new categories if necessary.
      • Add a short description of the example in the "Extensive Examples" section of features.md.
  • New miniapps:
    • All sample runs at the top of the miniapp source file work.
    • Update top-level makefile and makefile in corresponding miniapp directory.
    • Add the miniapp binary and any files generated by it to the top-level .gitignore file.
    • Update CMake build system:
      • Update the CMakeLists.txt file in the miniapps directory, if the new miniapp is in a new directory.
      • Add/update the CMakeLists.txt file in the new miniapp directory.
      • Consider adding a new test for the new miniapp.
    • List the new miniapp in doc/CodeDocumentation.dox
    • If new miniapps directory (e.g.miniapps/nurbs), add it to MINIAPP_SUBDIRS in the makefile.
    • If new miniapps directory (e.g.miniapps/nurbs), list it in doc/CodeDocumentation.conf.in
    • Companion pull request for documentation in mfem/web repo:
      • Update or add miniapp-specific documentation, see e.g. the src/meshing.md and src/electromagnetics.md files.
      • Add the description, labels and screenshots in src/examples.md and src/img.
      • The miniapps go at the end of the page, and are usually listed only under a specific "Application (PDE)" category.
      • Add a short description of the miniapp in the "Extensive Examples" section of features.md.
  • New capability:
    • All new public, protected, and private classes, methods, data members, and functions have full Doxygen-style documentation in source comments. Documentation should include descriptions of member data, function arguments and return values, template parameters, and prerequisites for calling new functions.
    • Pointer arguments and return values must specify whether ownership is being transferred or lent with the call.
    • Any new functions should include descriptions of their intended use e.g. for internal use only, user-facing, etc., along with references to example code whenever possible/appropriate.
    • Consider adding new sample runs in existing examples to highlight the new capability.
    • Consider saving cool simulation pictures with the new capability in the Confluence gallery (LLNL only) or submitting them, via pull request, to the gallery section of the mfem/web repo.
    • If this is a major new feature, consider mentioning it in the short summary inside README (rare).
    • List major new classes in doc/CodeDocumentation.dox (rare).
  • Update this checklist, if the new pull request affects it.
  • Run make unittest to make sure all unit tests pass.
  • Run the tests in tests/scripts.
  • (LLNL only) After merging:
    • Update internal tests to include the new features.

@justinlaughlin justinlaughlin marked this pull request as ready for review April 29, 2025 01:32
@justinlaughlin
Copy link
Contributor Author

Tagging @JacobLotz because this changes the edge_to_knot algorithm.
Tagging @david-kamensky because this changes the NURBSExtension patch + path topology constructor (does this work on your end?)

@tzanio
Copy link
Member

tzanio commented Apr 30, 2025

This PR is now under review (see the table in the PR description). To help with the review process, please do not force push to the branch.

@pazner
Copy link
Member

pazner commented Jun 3, 2025

@tzanio, could you take a look when you get a chance? @justinlaughlin mentioned needing this for other work.

Copy link
Member

@tzanio tzanio left a comment

Choose a reason for hiding this comment

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

Thanks @justinlaughlin !

@tzanio tzanio added the in-next label Jun 8, 2025
@tzanio
Copy link
Member

tzanio commented Jun 8, 2025

Merged in next for testing...

Adjust a tolerance in miniapps/nurbs/nurbs_solenoidal.cpp for macOS.

Fix typos in the miniapps/nurbs/makefile in the nurbs_solenoidal tests.

Re-formatting some long lines.
v-dobrev added a commit that referenced this pull request Jun 10, 2025
Resolved conflicts:
   miniapps/nurbs/makefile
@v-dobrev
Copy link
Member

Re-merged in next for testing...

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
Status: Review Now
Development

Successfully merging this pull request may close these issues.

5 participants