juliageometry / meta Goto Github PK

I wrote on the mailing list and was asked to post here for some discussion regarding a unified mesh representation.

I will write my use case and my implementation and maybe it can create some discussion / comments.

Currently, I am writing some code for Finite element analysis in Julia and obviously the concept of a mesh comes up. In my code I have two types of meshes, GeoMesh and FEMesh.

GeoMesh is a mesh in the geometrical sense. It contains nodes, elements and currently two types of sets, element sets and node sets. Later, I later also want to include edge and surface sets. At this moment I am not sure that having the sets a part of the actual mesh type is the best way.

My current implementation can be found here:
https://gist.github.com/KristofferC/a1a884a0af1818653c3d

By the way, I noticed today that I seem to have duplicted some stuff there that exists in GeometricalPredicates.jl

One problem with this implementation is that GeoMesh.elements is type unstable. The reason for this is that a priori I do not know what type of elements will be used. However, for my purpose that is ok since I just don't do any computations with GeoMesh, I just use it to hold some information. I realize for other use cases this is unacceptable.

FEMesh has a similar structure to GeoMesh except the type of nodes and elements are different. Here the elements are actual finite elements. These includes much more information than the simple geometrical elements. For example, a finite element include what type of interpolator is used to interpolate fields inside the element and what type of degrees of freedom exist in the nodes etc.

The FEMesh is created from the GeoMesh by a function that also takes a mapping of what finite element each geometric element should become.

To visualize the mesh and the results I currently use Python's VTK bindings and call them with PyCall similarly to this (except I also give the values of the strain/stress tensors at the nodes): https://gist.github.com/KristofferC/9a989a2c0518bb70009c

It would be nice if I could just use some of the stuff under the JuliaGeometry organization instead of rolling my own so if you have any idea how to do that, feel free to share.

Best regards, Kristoffer Carlsson.

After the extrication of geometries from Base, I think there's been development that took place across enough packages, e.g.

• https://github.com/JuliaLang/Graphics.jl
• https://github.com/nolta/Winston.jl
• https://github.com/JuliaGeometry/GeometryTypes.jl
• https://github.com/JuliaGeometry/GeometricalPredicates.jl
• https://github.com/dcjones/Compose.jl
• https://github.com/JuliaGeo/GeoInterface.jl
• https://github.com/JuliaGeo/LibGEOS.jl
• https://github.com/Keno/Shapefile.jl
• https://github.com/zyedidia/SFML.jl

for us to want to re-visit the conversation again, and hash things out abit. I'll talk more about it tomorrow (in the talk on JuliaGeo), but in the meantime it'll be good to start getting responses for a meetup for julia developers who're in the Boston area.

(Tentative) Date/time: Saturday, 27 June 2015, 10 AM

Do reply with the dates/times of your availability, so I can book a room.

cc: @dcjones @SimonDanisch @sjkelly @wkearn @jminardi @timholy @shashi @Keno @lobingera @ViralBShah @rohitvarkey @KristofferC @garborg @randyzwitch @jheinen @tedsteiner @zyedidia, others?

Hi there,
I thought its about time that I write down, what I expect from Compose/3D and share some thoughts on how I think it could be implemented.

What I expect from Compose/3D:

• composing objects with boundingboxes with different unites in a space(context) with different units
• result of compose should be a tree of signals of transformation matrices. This does not account for attributes. Maybe it should rather be a tree of Contexts and the context type includes attributes and a transformation matrix. The results should then all be in the same space! How far away is this from the current implementation!?
• Integrate attributes. This one is a little tricky. Like its currently done in Compose (context(0.5, 0.5, 0.5, 0.5), circle(), fill(...))` seems to me like its either slow or complicated to implement when a lot of flexibility is needed. I need to think about this one, maybe I just need to wrap my head around it.
  So far I'm more into visualize(primitive, kwarg1=x, kwarg2=z...). Nice thing about how compose currently handles it is, that you can globally set style attributes for a context which seems to be desirable! So maybe its worth rethinking for me and I just need to figure out what this means for GLVisualize.
• by composing I think of alignments. Coming from photoshop this means something like this to me:
  I think this is different, or higher level from what compose does. You would align by creating a new context, which e.g. has the middle of the parent context as its origin, right?!
• unifying Escher and Compose. The previously mentioned alignments seem to be implemented in Escher. Also, the Tile abstraction seems to come very close to what I think of what a composable graphic looks like. A blackbox with arbitrary renderable objects inside + boundingbox.
• deep integration of signals. So you could say something like center at Signal(Point2(0.5)), or hskip(Signal(0.5pt)). Also use signals of boundingboxes/contexts. Hide signals inside a tile/composable graphic. This would mean we can integrate a lot of dynamic information without ever recomposing.
• I'm a big fan of using Julia objects for retrieving layouts. So a vector of things implies a list. A matrix implies a grid of things. A dict is a two column kind of structure. So if you want to have a grid of images, you would just put them into a matrix. You could supply optional parameters to change the padding, alignment, looks, etc. I like this because it gives often used julia types a sensible default visualization which is nice for visual debugging.

If we can agree on these points, I will help @rohitvarkey with Compose3D and replace my current interface in GLVisualize with it. This would mean GLVisualize becomes a backend for Compose3D, and @rohitvarkey should start to move out the WebGL functionality.

Outcome of Geometry Meetup AKA Geometry Primitives

It was just me and @garborg, but we had a very good talk!
I think the conclusion was along the lines, that we all should experiment around with different vector (fixed vector) representations, to see what feels most natural for some specific domain. If everyone is a little bit experimental and has a clearer picture in the end, we can better decide what a good vector type should look like.
I will experiment with FixedSizeArrays a bit. I will implement a few different versions and play around with them. Some candidates are in: https://gist.github.com/SimonDanisch/76c82631d38f12b2e350#file-geometry-jl .

One thing @garborg and I discussed was if including the space that a vector/point is in, e.g. spherical, camera space, etc makes sense. The gain: we would always know in which space we are, which makes interfacing easier and should reduce mistakes. Downside: complicates implementation quite a bit and might also make working with vectors annoying.

Random thoughts

NTuple seems to be more of a typealias, even though it is a different type under the hood.
Consider:

julia> test() = (1,2,3)
julia> test2() = (1f0,2,3)
julia> @code_llvm test()
define [3 x i64] @julia_test_1601() {
top:
  ret [3 x i64] [i64 1, i64 2, i64 3]
}
julia> @code_llvm test2()
define { float, i64, i64 } @julia_test2_1609() {
top:
  ret { float, i64, i64 } { float 1.000000e+00, i64 2, i64 3 }
}

We should keep this in mind. I think the implications are not that grave, but it could be nasty when compiling to the GPU.

@dcjones said he wants different measures inside one point. I'm not entirely convinced, that the use case he mentioned (Point2(2s, 2mm)) is that appealing.
It complicates things quite a bit and it seems to be more natural to have two seperated vectors, one for the time and one for the spatial dimension.
A more intriguing use case (at least for me and OpenGL) is that there are color types with different precisions per channel. This could easily be included in FixedSizeArrays, as only getindex and the eltype function are different. But we would need a more fine grained inheritance tree for that.

Conclusion

I hope this is helpful ;)
Let me know if you have questions!

CC: @dcjones @sjkelly @wkearn @jminardi @timholy @shashi @Keno @lobingera @ViralBShah @rohitvarkey @KristofferC @garborg @randyzwitch @jheinen @tedsteiner @zyedidia @yeesian @jminardi @dreammaker

If you don't want to get pinged, please notice me. These are the people I consider to be interested in the development of this.

Best,
Simon

As I mentioned in #7 I wanted to open an issue to collect some use cases!
These are for 2D and 3D!

Some guidelines:
First post the most native format you're data is in.
E.g.:
File with two columns of floats -> myread(::file) -> Array{Float32, 2}
Then your dream plotting command together with a description of the most perfect visualization you can possibly think of for this kind of data, best together with a picture.
E.g:

a = data
plot(x=Seconds(a[1:end, 1]), y=Millimeter(a[1:end, 2])) # assuming views don't copy
plot(convert(Point{mm, s}, a))

Now that MarchingCubes.jl is a dependency of UnicodePlots.jl, I'd like to transfer the repository to an organization in order to ease future maintenance and/or contributions.

I believe it fits in JuliaGeometry since Meshing.jl also supports an alternative implementation of Marching Cubes.

Do you think this is relevant ?

@njwilson23 and I have this (partial) implementation of Logg 2012 mesh, which is what FEnICS uses:
https://bitbucket.org/maurow/lmesh.jl

Any interest in adding this to JuliaGeometry?

It was great to meet many of you at JuliaCon, and I think it is really great we are willing to coordinate our efforts on geometry for Julia. Below is a link for scheduling the Julia Geometry Meetup:

http://www.when2meet.com/?3190881-OYJVq

Please use UTC when entering your schedule. We will choose the date with the best availability for everyone, and I will send a link to the google-hangout. Below is the start of a rough agenda. Please add anything you would like to discuss or demo:

https://github.com/JuliaGeometry/meta/wiki/July-2015-Meetup

CC: @dcjones @SimonDanisch @sjkelly @wkearn @jminardi @timholy @shashi @Keno @lobingera @ViralBShah @rohitvarkey @KristofferC @garborg @randyzwitch @jheinen @tedsteiner @zyedidia @yeesian @jminardi @dreammaker

JuliaCon meeting: #5

@twadleigh should we could transfer Meshes.jl into this repository? I believe you have a pending invite for the org.

cc @SimonDanisch