Add support for hex objects

[njansson]

This is the first step towards using the aabb search tree for interpolation

[njansson]

Could this be implemented for the generic element_t instead to avoid having to implement it for all variants?

Not sure, max can't handle array ranges afaik, which could make it difficult for generic element

[njansson]

Could this be implemented for the generic element_t instead to avoid having to implement it for all variants?

Not sure, max can't handle array ranges afaik, which could make it difficult for generic element

Right, but how would it be different? would it not just be doable in a loop through the entries of element_t%pts like we both did with tri_t and hex_t? Except we both hardcoded the loops, and used the trick that max does accept abitrary numbers of inputs and does the looping for you.

True, we could probably do a loop, over the pts array, and do several max/min checks

[timfelle]

Could this be implemented for the generic element_t instead to avoid having to implement it for all variants?

Not sure, max can't handle array ranges afaik, which could make it difficult for generic element

Right, but how would it be different? would it not just be doable in a loop through the entries of element_t%pts like we both did with tri_t and hex_t? Except we both hardcoded the loops, and used the trick that max does accept abitrary numbers of inputs and does the looping for you.

True, we could probably do a loop, over the pts array, and do several max/min checks

I am not exactly sure how the overload resolution would function in fortran in that case though. Would tri_t and hex_t trigger the element_t function since they are extending it or how would that work?

[njansson]

Could this be implemented for the generic element_t instead to avoid having to implement it for all variants?

Not sure, max can't handle array ranges afaik, which could make it difficult for generic element

Right, but how would it be different? would it not just be doable in a loop through the entries of element_t%pts like we both did with tri_t and hex_t? Except we both hardcoded the loops, and used the trick that max does accept abitrary numbers of inputs and does the looping for you.

True, we could probably do a loop, over the pts array, and do several max/min checks

I am not exactly sure how the overload resolution would function in fortran in that case though. Would tri_t and hex_t trigger the element_t function since they are extending it or how would that work?

Yes, as long as you access parts define din the base type it works without a select block

[timfelle]

So, the point_t is based on strictly double precision while the aabb_t uses the rp type to define the precision. I guess I need to be more considerate when setting up the precision of stuff. Do we intend to only use the rp one to define fields and phycis but in general keeping goemetric objects on full double precision?

[timofeymukha]

So, the point_t is based on strictly double precision while the aabb_t uses the rp type to define the precision. I guess I need to be more considerate when setting up the precision of stuff. Do we intend to only use the rp one to define fields and phycis but in general keeping goemetric objects on full double precision?

Could be wrong, but I think that was the idea.

[njansson]

So, the point_t is based on strictly double precision while the aabb_t uses the rp type to define the precision. I guess I need to be more considerate when setting up the precision of stuff. Do we intend to only use the rp one to define fields and phycis but in general keeping goemetric objects on full double precision?

Could be wrong, but I think that was the idea.

The original idea was to make sure that the mesh is always in double, hence point being double.

For the aabb tree, don't we need the higher precision as well?

[timfelle]

So, the point_t is based on strictly double precision while the aabb_t uses the rp type to define the precision. I guess I need to be more considerate when setting up the precision of stuff. Do we intend to only use the rp one to define fields and phycis but in general keeping goemetric objects on full double precision?

Could be wrong, but I think that was the idea.

The original idea was to make sure that the mesh is always in double, hence point being double.

For the aabb tree, don't we need the higher precision as well?

Yes we do. I had just been lazy and set everything to kind=rp, since locally i always run in double precision. I will make sure to think more about it going forward.