Git Product home page Git Product logo

Comments (5)

wdeconinck avatar wdeconinck commented on August 16, 2024

There are a number of mesh::actions that need to be applied that may be required only when creating the functionspace::NodeColumns
Other mesh actions may be required when creating functionspace::EdgeColumns
I understand it is unexpected. I have struggled to find a good way.

At the point of mesh-creation you may not yet have the logic to what you want to do with it, as that may depend on a configurable numerical method chosen.

One should use NodeColumns::size(), which would be what you expect.
Creating subsequently another NodeColumns with smaller halo should also return what you expect.

from atlas.

havogt avatar havogt commented on August 16, 2024

Maybe a function like

atlas::functionspace::NodeColumns enableNodeColumns(mesh, [options]);

would make it more obvious that the mesh changes.

At the point of mesh-creation you may not yet have the logic to what you want to do with it, as that may depend on a configurable numerical method chosen.

Are there useful operations you could already do with the mesh, before you have a functionsspace on it? Why do you want to create the mesh before you have all required information on how you want to construct it?
Of course, the code I am dealing with are very simple standalone examples, so I don't see the complication you might encounter when implementing a full model.

from atlas.

wdeconinck avatar wdeconinck commented on August 16, 2024

I have considered your proposed function enableNodeColumns versus a NodeColumns constructor, and in the end the API would be the same, bar a different name.
The paradigm of having it in a constructor is that the functionspace object is always created correctly and does not depend on a disjoint creator function.

The mesh should be seen as a more heavy mutable datastructure in support for various function spaces. The Finite Volume scheme e.g. requires 2 functionspaces: NodeColumns, functionspace::EdgeColumns.
Atlas provides a 'fvm::Method', which taken a mesh and options, constructs both function spaces within its Method object. Again the mesh will be adapted.
I may have to document all this better and more clearly

All this said, the functionspace::NodeColumns::size() function, when created with the right halo option, should return you just the number of points in the mesh including the right halo.
Halo's in the mesh are currently always constructed incrementally so node numbering for each halo is following the previous halo nodes. This allows for multiple functionspace::NodeColumns instances with different halos to use the same mesh

from atlas.

havogt avatar havogt commented on August 16, 2024

I have considered your proposed function enableNodeColumns versus a NodeColumns constructor, and in the end the API would be the same, bar a different name.

There is a big difference: enableNodeColumns documents its side-effect in the name. A side-effect on an argument of a constructor is maximally hidden.

All this said, the functionspace::NodeColumns::size() function, when created with the right halo option, should return you just the number of points in the mesh including the right halo.
Halo's in the mesh are currently always constructed incrementally so node numbering for each halo is following the previous halo nodes. This allows for multiple functionspace::NodeColumns instances with different halos to use the same mesh

I think I understand the concept of functionspace much better now. I was thinking of it as an object which just creates fields. But it is more, it also defines the iteration space on a mesh. In my use-case I don't want to create fields, just iterate over all nodes and access neighbors. This should be done via the function space, not the Mesh.nodes(), right?

If that's right, maybe Mesh.nodes() (and all other methods of Mesh which expose the side effect of the functionspace constructor) could be made private? Then I would be less concerned with this pattern.

from atlas.

havogt avatar havogt commented on August 16, 2024

And what about the functions to get metric fields, like Mesh.nodes().field("dual_volumes")? Can I get this field via a functionspace? Because with my new understanding of functionspace, I should be able to get this field with different number of halos, depending on the function space.

from atlas.

Related Issues (20)

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.