Thank you Tim for your suggestion about creating functions returning iterators. That sounds indeed like a very clean way to do it.
Mauro, thanks for the link. I read the paper by Logg and it seems interesting. Do you have any references for how the mapping from the cells to the actual finite elements is done? While writing my FEM code, I have had some troubles with type stability. In FEM you can have arbitrary many type of finite elements and materials at different parts of the mesh and having it all come together in a type stable way is non trivial in my opinion. Right now, I use something like this to represent the geometric mesh: https://gist.github.com/KristofferC/74bfcc0c79897f3b5754 and I then apply finite element types and material types to different element sets in the geometric mesh. I then create a bunch of "FESections" that all are parameterized by the finite element type and material type. There was some discussion about it here: https://github.com/JuliaGeometry/meta/issues/3 On Wednesday, April 8, 2015 at 5:46:12 PM UTC+2, Mauro wrote: > > Nat and I once started on a mesh library which implements some of that: > https://bitbucket.org/maurow/mesh.jl > but it has gone a bit stale. > > In the spirit of Tim's response, it defines a big mesh datatype and then > helper dataytpes, for instance Vertices, which are just a thin wrapper > around the mesh. So, then you can do: > > mesh = ... # construct the mesh > vertices = Vertices(mesh) > n_vertices = length(vertices) > edges = Edges(mesh) > for v in vertices > ... > end > v10 = vertices[10] # get a single vertex > > (I hope to start using it again in a few weeks to do some FEM work.) > > On Wed, 2015-04-08 at 15:35, Kristoffer Carlsson <kcarl...@gmail.com > <javascript:>> wrote: > > I come from a Python background where direct access to fields in for > > example classes with the dot notation is very common. > > > > However, from what I have seen in different conversations, accessing > fields > > directly is not really Julian. Sort of a "fields are an implementation > > detail" mindset, and "what is important are the functions". > > > > Here is an example of a type hierarchy that is a little bit similar to > > types I am working with now: > > > > type Element > > vertices::Vector{Int} > > end > > > > type Node > > coordinates::Vector{Float64} > > id::Int > > end > > > > type FESection > > elements::Vector{Elements} > > nodes::Vector{Nodes} > > end > > > > type Mesh > > sections::Vector{FESection} > > end > > > > Now, let's say that I want to write a function to loop over all > vertices. > > One way (which I would do in Python is): > > > > mesh = Mesh(.....) > > for section in mesh.sections > > for element in section.elements > > for vertices in element.vertices > > blah bla > > end > > end > > end > > > > > > > > However, this accesses the fields directly. Would it be more Julian to > > write getters for the fields? Since Julia does not have @property like > > Python I realize that by accessing the fields you commit to exactly the > > name of the field and it's type while with a getter it would be more > > flexible. > > > > Best regards, > > Kristoffer Carlsson > >
