Implementing direct navigator #948
Conversation
beomki-yeo
force-pushed
the
direct-navigator
branch
from
b49930b to
d071cf0
Compare
beomki-yeo
added
enhancement
beomki-yeo
force-pushed
the
direct-navigator
branch
4 times, most recently
from
263822f to
b84990a
Compare
beomki-yeo
force-pushed
the
direct-navigator
branch
12 times, most recently
from
2df589c to
4263639
Compare
core/include/detray/navigation/intersection/ray_cylinder_portal_intersector.hpp
Show resolved
Hide resolved
| vecmem::data::vector_buffer<detray::geometry::barcode> seqs_buffer{ | ||
| 100u, host_mr, vecmem::data::buffer_type::resizable}; | ||
| vecmem::copy m_copy; | ||
| m_copy.setup(seqs_buffer)->wait(); |
There was a problem hiding this comment.
It seems this is quite complicated for host code. A device vector can simply be built from the view of a vecmem::vector, or not?
There was a problem hiding this comment.
Resizable buffer needs this copy.setup to build a device vector
There was a problem hiding this comment.
Sure, but I don't understand why you need a buffer in the first place? Does the following not work?
vecmem::vector<geometry::barcode> seq_vector{host_mr};
auto seq_view = detray::get_data(seq_vector);
There was a problem hiding this comment.
That will be easier in the host test.
However, during the GPU KF, vecmem::buffer will be much easier to use. So the code above is the proof of concept for the KF implementation
| sf.is_portal() ? darray<scalar_type, 2>{cfg.min_mask_tolerance, | ||
| cfg.max_mask_tolerance} | ||
| : darray<scalar_type, 2>{cfg.min_mask_tolerance, | ||
| cfg.max_mask_tolerance}, | ||
| static_cast<scalar_type>(cfg.mask_tolerance_scalor), | ||
| static_cast<scalar_type>(cfg.overstep_tolerance)); |
There was a problem hiding this comment.
Tha mask tolerance and overstepping tolerance are not needed for direct navigation, I believe
| sf.is_portal() ? darray<scalar_type, 2>{cfg.min_mask_tolerance, | |
| cfg.max_mask_tolerance} | |
| : darray<scalar_type, 2>{cfg.min_mask_tolerance, | |
| cfg.max_mask_tolerance}, | |
| static_cast<scalar_type>(cfg.mask_tolerance_scalor), | |
| static_cast<scalar_type>(cfg.overstep_tolerance)); | |
| darray<scalar_type, 2>{cfg.min_mask_tolerance, | |
| cfg.min_mask_tolerance}, | |
| 0.f, | |
| -detail::invalid_value<scalar_type>()); |
There was a problem hiding this comment.
Without mask tolerance, the surfaces can get missed during the backward propagation.
The overstep tolerance could be any values technically but I worry the situation where the navigation is trapped in an infinite loop.
There was a problem hiding this comment.
The direct navigator should not miss a surface when the intersection is outside or it would run precisely into the same problems the current navigator does. Or am I missing something?
The overstep tolerance could be any values technically but I worry the situation where the navigation is trapped in an infinite loop.
I am sorry, I cannot follow on how it could get stuck this way. Can you explain what you mean, please?
There was a problem hiding this comment.
Anyway you asked..
There was a problem hiding this comment.
Ah, OK, that is interesting! Can you show me how to reproduce this?
There was a problem hiding this comment.
And in our geometries during tracking, is there a configuration you found that I can try?
Just make a telescope geometry if you want to try. Do you need a exact number and codes? No way that I am going to write it for you. You just don't like this or what??
There was a problem hiding this comment.
I was asking, because I would like to debug this case and was wondering if you had already encountered this and could give me a starting point... that is all, I am sorry
There was a problem hiding this comment.
I don't think you would ever try it on your own. you just want to prove that I have not encountered this actually so shut down my argument, don't you?
As I said, set it to -MAX with the configuration object if you want.
There was a problem hiding this comment.
No, this problem makes sense to me and I had not thought of it before. I am genuinely sorry if you feel that way
beomki-yeo
force-pushed
the
direct-navigator
branch
from
13459d3 to
23220b5
Compare
beomki-yeo
force-pushed
the
direct-navigator
branch
2 times, most recently
from
166c9a6 to
7845fad
Compare
beomki-yeo
force-pushed
the
direct-navigator
branch
from
7845fad to
b4635d4
Compare
|
This PR implements direct navigator.
The direct navigator runs on the input surface sequence which include all types of surfaces (passive, sensitive and portals)
The input sequence can be collected from previous run of propagator using
barcode_sequenceractorIt is also designed to work with both forward and backward directions.
The PR also fixes the bug that
pathis not written in the cylinder intersections whenpath < overstep tolerance, which occasionally killed the propagation with direct navigator and small overstep tolerance.Also This PR sets the volume in the propagator constructor with bound parameter inputs.