I noticed in all of the data points we have space coordinates but no time coordinates at all. Are we to assume that all of the hits are nearly simultaneous?
", "messages": [ { "id": "321727", "postDate": "05/01/2018 20:03:30", "content": "I noticed in all of the data points we have space coordinates but no time coordinates at all. Are we to assume that all of the hits are nearly simultaneous?
", "rawMarkdown": "I noticed in all of the data points we have space coordinates but no time coordinates at all. Are we to assume that all of the hits are nearly simultaneous?", "votes": null }, { "id": "321730", "postDate": "05/01/2018 20:08:26", "content": "The current technology is not (yet) at the stage to achieve detectors with a good enough timing resolution such that this could reliably be used. Hence, hit time information is not available.
", "rawMarkdown": "The current technology is not (yet) at the stage to achieve detectors with a good enough timing resolution such that this could reliably be used. Hence, hit time information is not available.", "votes": null }, { "id": "321739", "postDate": "05/01/2018 20:29:38", "content": "I see, but can we at least assume that the hits are in time sequence order?
", "rawMarkdown": "I see, but can we at least assume that the hits are in time sequence order?", "votes": null }, { "id": "321742", "postDate": "05/01/2018 20:36:07", "content": "The particles move from the center of the detector outwards, so - yes, indeed, they are ordered in that sense. However, within the dataset they are ordered like a detector would read them out, module by module.
", "rawMarkdown": "The particles move from the center of the detector outwards, so - yes, indeed, they are ordered in that sense. However, within the dataset they are ordered like a detector would read them out, module by module.", "votes": null }, { "id": "321773", "postDate": "05/01/2018 21:20:55", "content": "From the detector point-of-view all hits occur at the same time. The time it takes for the particles to move through the detector is much shorter than the time resolution of the detector modules.
", "rawMarkdown": "From the detector point-of-view all hits occur at the same time. The time it takes for the particles to move through the detector is much shorter than the time resolution of the detector modules.", "votes": null }, { "id": "321820", "postDate": "05/02/2018 00:59:34", "content": "So, what about the modules that have multiple particles hitting them. Don't we even have information on the order of hits occurring at a single module?
", "rawMarkdown": "So, what about the modules that have multiple particles hitting them. Don't we even have information on the order of hits occurring at a single module?", "votes": null }, { "id": "321823", "postDate": "05/02/2018 01:12:36", "content": "I am not a physicist.
\n\nThere is a description of the detector around someplace. Think of it as Detector is made up of Modules and a Module is made up of Cells. Some cells are further divided into channels. The data provides data down to the cell/channel level and the energy 'deposited' into that cell. AFAIK the cell can't tell between two particles interacting with the cell or one particle interacting one or more times.
", "rawMarkdown": "I am not a physicist.\n\nThere is a description of the detector around someplace. Think of it as Detector is made up of Modules and a Module is made up of Cells. Some cells are further divided into channels. The data provides data down to the cell/channel level and the energy 'deposited' into that cell. AFAIK the cell can't tell between two particles interacting with the cell or one particle interacting one or more times.", "votes": null }, { "id": "321939", "postDate": "05/02/2018 07:20:45", "content": "Here's the description document:\nhttps://cernbox.cern.ch/index.php/s/tkF9YFCrYu8auWw
\n\nIn fact, we simplified the problem: if a cell was hit by two particles (this is an rather rare process) we produce two individual measurements in order to allow you to do a unique assignment of a hit_id to a track_id. In reality, these channels would merge, but for the sake of this challenge we split them already for you beforehand.
\n\n\nThe particles move from the center of the detector outwards, so - yes, indeed, they are ordered in that sense.
\n
@asalzburger By looking at the tracks it seems that it's not always the case, given that the origin of the particle is not exactly at the center. I mean that I think the order of hits the particle took is not the same as hits ordered by distance from the center. I think some way to recover ground truth order would be really useful.
", "rawMarkdown": "> The particles move from the center of the detector outwards, so - yes, indeed, they are ordered in that sense. \n\n@asalzburger By looking at the tracks it seems that it's not always the case, given that the origin of the particle is not exactly at the center. I mean that I think the order of hits the particle took is not the same as hits ordered by distance from the center. I think some way to recover ground truth order would be really useful.", "votes": null }, { "id": "322013", "postDate": "05/02/2018 09:51:25", "content": "Well spotted, Konstantin. Those particles produced not at the interaction region are so-called secondaries that are created from interactions of primary particles (the ones from the initial collision) with detector material. As these interactions go, they are roughly following the initial direction, but usually have less hits and lower momentum.
The truth can be recovered for the training dataset, however, in reality we can not access it -- the particle doesn't leave a position nor momentum at it's creation - otherwise our job would be easy :-)
", "rawMarkdown": "The *truth* can be recovered for the training dataset, however, in reality we can not access it -- the particle doesn't leave a position nor momentum at it's creation - otherwise our job would be easy :-)", "votes": null }, { "id": "322021", "postDate": "05/02/2018 10:02:47", "content": "Thanks for clarification Andreas.
\n\n\n\n\nThe truth can be recovered for the training dataset
\n
Do you mean it is explicitly present in the train dataset uploaded to Kaggle (I coun't find it)? Or sorting by distance from the origin is the best we have? I understand that it's not available at test time.
", "rawMarkdown": "Thanks for clarification Andreas.\n\n> The truth can be recovered for the training dataset\n\nDo you mean it is explicitly present in the train dataset uploaded to Kaggle (I coun't find it)? Or sorting by distance from the origin is the best we have? I understand that it's not available at test time.", "votes": null }, { "id": "322023", "postDate": "05/02/2018 10:12:23", "content": "It is not explicitely stored in the training dataset. Since the particles do not all originate from the origin you should use the absolute distance along the z-axis from the particle vertex for this.
", "rawMarkdown": "It is not explicitely stored in the training dataset. Since the particles do not all originate from the origin you should use the absolute distance along the z-axis from the particle vertex for this.", "votes": null }, { "id": "322033", "postDate": "05/02/2018 10:23:53", "content": "You can access the truth position and momentum (=direction) at every hit, from this it should be best determined. We did not simulate time information as it is not in reach for us (yet) from a technology standpoint.
", "rawMarkdown": "You can access the truth position and momentum (=direction) at every hit, from this it should be best determined. We did not *simulate* time information as it is not in reach for us (yet) from a technology standpoint.", "votes": null }, { "id": "322035", "postDate": "05/02/2018 10:24:48", "content": "Sorting by z-axis works great, thanks!
", "rawMarkdown": "Sorting by z-axis works great, thanks!", "votes": null }, { "id": "322229", "postDate": "05/02/2018 15:30:06", "content": "\n\n\nIn fact, we simplified the problem: if a cell was hit by two particles (this is an rather rare process) we produce two individual measurements in order to allow you to do a unique assignment of a hit_id to a track_id. In reality, these channels would merge, but for the sake of this challenge we split them already for you beforehand.
\n
Well, I wasn't asking about a cell being hit by two particles, but rather a module being hit by multiple particles. Looking at the statistics -- modules that get hits in an event tend to get on average 6 different particles that hit them, which is clearly not rare. So, to repeat my question -- do we not know the order of these multiple hits on the same module?
", "rawMarkdown": "> In fact, we simplified the problem: if a cell was hit by two particles (this is an rather rare process) we produce two individual measurements in order to allow you to do a unique assignment of a hit_id to a track_id. In reality, these channels would merge, but for the sake of this challenge we split them already for you beforehand.\n\nWell, I wasn't asking about a cell being hit by two particles, but rather a module being hit by multiple particles. Looking at the statistics -- modules that get hits in an event tend to get on average 6 different particles that hit them, which is clearly not rare. So, to repeat my question -- do we not know the order of these multiple hits on the same module?", "votes": null }, { "id": "322236", "postDate": "05/02/2018 15:41:34", "content": "Sorry, misunderstood. All the particles - as far as we can measure - arrive at one specific module at the same time.
\n\nMore info:\nThey come from the same beam-beam interaction which happens mostly within a length of ~5-10 cm on the global z axis, and to a good approximation they travel with the speed of light. We would need a technology to resolve the geometrical path difference divided by the speed of light to resolve this. That technology doesn't exist yet.
", "rawMarkdown": "Sorry, misunderstood. All the particles - as far as we can measure - arrive at one specific module at the same time. \n\nMore info:\nThey come from the same beam-beam interaction which happens mostly within a length of ~5-10 cm on the global z axis, and to a good approximation they travel with the speed of light. We would need a technology to resolve the geometrical path difference divided by the speed of light to resolve this. That technology doesn't exist yet.", "votes": null }, { "id": "322237", "postDate": "05/02/2018 15:42:08", "content": "We do not. Within one event the hits appear simultaneous to the detector.
\n\nTo put the average 6 hits/module/event into perspective: a module is the smallest detector component and can have a surface area between 2x2 cm² and 10x10 cm² (roughly). Each module surface is gridded into cells or pixels that can range in size from 0.05x0.0565 µm² to 0.12x10.8 mm². With 6 hits, only a tiny fraction of the possible cells is active. Separating these different active cells/pixels spatially is therefore not an issue.
", "rawMarkdown": "We do not. Within one event the hits appear simultaneous to the detector.\n\nTo put the average 6 hits/module/event into perspective: a module is the smallest detector component and can have a surface area between 2x2 cm² and 10x10 cm² (roughly). Each module surface is gridded into cells or pixels that can range in size from 0.05x0.0565 µm² to 0.12x10.8 mm². With 6 hits, only a tiny fraction of the possible cells is active. Separating these different active cells/pixels spatially is therefore not an issue.", "votes": null }, { "id": "322846", "postDate": "05/03/2018 19:07:22", "content": "\n\n\nSorting by z-axis works great, thanks!
\n
Wouldn't it be better to sort by distance from origin?
", "rawMarkdown": "> Sorting by z-axis works great, thanks!\n\nWouldn't it be better to sort by distance from origin?", "votes": null }, { "id": "322877", "postDate": "05/03/2018 20:38:52", "content": "\n\n\nWouldn't it be better to sort by distance from origin?
\n
I think no, I tried both ways - it's hard to describe it in words, but the helix is usually aligned with z-axis but the path along the helix can have x and y decreasing faster than z is increasing, so getting closer to origin
", "rawMarkdown": "> Wouldn't it be better to sort by distance from origin?\n\nI think no, I tried both ways - it's hard to describe it in words, but the helix is usually aligned with z-axis but the path along the helix can have x and y decreasing faster than z is increasing, so getting closer to origin", "votes": null } ], "comments": [ { "id": 321730, "author_name": "asalzburger", "author_url": "", "post_date": "05/01/2018 20:08:26", "content": "The current technology is not (yet) at the stage to achieve detectors with a good enough timing resolution such that this could reliably be used. Hence, hit time information is not available.
", "votes": null, "replies": [ { "id": 321739, "author_name": "nimararora", "author_url": "", "post_date": "05/01/2018 20:29:38", "content": "I see, but can we at least assume that the hits are in time sequence order?
", "votes": null, "replies": [] }, { "id": 321742, "author_name": "asalzburger", "author_url": "", "post_date": "05/01/2018 20:36:07", "content": "The particles move from the center of the detector outwards, so - yes, indeed, they are ordered in that sense. However, within the dataset they are ordered like a detector would read them out, module by module.
", "votes": null, "replies": [] }, { "id": 321773, "author_name": "msmk00", "author_url": "", "post_date": "05/01/2018 21:20:55", "content": "From the detector point-of-view all hits occur at the same time. The time it takes for the particles to move through the detector is much shorter than the time resolution of the detector modules.
", "votes": null, "replies": [] }, { "id": 321820, "author_name": "nimararora", "author_url": "", "post_date": "05/02/2018 00:59:34", "content": "So, what about the modules that have multiple particles hitting them. Don't we even have information on the order of hits occurring at a single module?
", "votes": null, "replies": [] }, { "id": 321823, "author_name": "mcvicuna", "author_url": "", "post_date": "05/02/2018 01:12:36", "content": "I am not a physicist.
\n\nThere is a description of the detector around someplace. Think of it as Detector is made up of Modules and a Module is made up of Cells. Some cells are further divided into channels. The data provides data down to the cell/channel level and the energy 'deposited' into that cell. AFAIK the cell can't tell between two particles interacting with the cell or one particle interacting one or more times.
", "votes": null, "replies": [] }, { "id": 321939, "author_name": "asalzburger", "author_url": "", "post_date": "05/02/2018 07:20:45", "content": "Here's the description document:\nhttps://cernbox.cern.ch/index.php/s/tkF9YFCrYu8auWw
\n\nIn fact, we simplified the problem: if a cell was hit by two particles (this is an rather rare process) we produce two individual measurements in order to allow you to do a unique assignment of a hit_id to a track_id. In reality, these channels would merge, but for the sake of this challenge we split them already for you beforehand.
\n\n\nThe particles move from the center of the detector outwards, so - yes, indeed, they are ordered in that sense.
\n
@asalzburger By looking at the tracks it seems that it's not always the case, given that the origin of the particle is not exactly at the center. I mean that I think the order of hits the particle took is not the same as hits ordered by distance from the center. I think some way to recover ground truth order would be really useful.
", "votes": null, "replies": [] }, { "id": 322013, "author_name": "asalzburger", "author_url": "", "post_date": "05/02/2018 09:51:25", "content": "Well spotted, Konstantin. Those particles produced not at the interaction region are so-called secondaries that are created from interactions of primary particles (the ones from the initial collision) with detector material. As these interactions go, they are roughly following the initial direction, but usually have less hits and lower momentum.
The truth can be recovered for the training dataset, however, in reality we can not access it -- the particle doesn't leave a position nor momentum at it's creation - otherwise our job would be easy :-)
", "votes": null, "replies": [] }, { "id": 322021, "author_name": "lopuhin", "author_url": "", "post_date": "05/02/2018 10:02:47", "content": "Thanks for clarification Andreas.
\n\n\n\n\nThe truth can be recovered for the training dataset
\n
Do you mean it is explicitly present in the train dataset uploaded to Kaggle (I coun't find it)? Or sorting by distance from the origin is the best we have? I understand that it's not available at test time.
", "votes": null, "replies": [] }, { "id": 322023, "author_name": "msmk00", "author_url": "", "post_date": "05/02/2018 10:12:23", "content": "It is not explicitely stored in the training dataset. Since the particles do not all originate from the origin you should use the absolute distance along the z-axis from the particle vertex for this.
", "votes": null, "replies": [] }, { "id": 322033, "author_name": "asalzburger", "author_url": "", "post_date": "05/02/2018 10:23:53", "content": "You can access the truth position and momentum (=direction) at every hit, from this it should be best determined. We did not simulate time information as it is not in reach for us (yet) from a technology standpoint.
", "votes": null, "replies": [] }, { "id": 322035, "author_name": "lopuhin", "author_url": "", "post_date": "05/02/2018 10:24:48", "content": "Sorting by z-axis works great, thanks!
", "votes": null, "replies": [] }, { "id": 322229, "author_name": "nimararora", "author_url": "", "post_date": "05/02/2018 15:30:06", "content": "\n\n\nIn fact, we simplified the problem: if a cell was hit by two particles (this is an rather rare process) we produce two individual measurements in order to allow you to do a unique assignment of a hit_id to a track_id. In reality, these channels would merge, but for the sake of this challenge we split them already for you beforehand.
\n
Well, I wasn't asking about a cell being hit by two particles, but rather a module being hit by multiple particles. Looking at the statistics -- modules that get hits in an event tend to get on average 6 different particles that hit them, which is clearly not rare. So, to repeat my question -- do we not know the order of these multiple hits on the same module?
", "votes": null, "replies": [] }, { "id": 322236, "author_name": "asalzburger", "author_url": "", "post_date": "05/02/2018 15:41:34", "content": "Sorry, misunderstood. All the particles - as far as we can measure - arrive at one specific module at the same time.
\n\nMore info:\nThey come from the same beam-beam interaction which happens mostly within a length of ~5-10 cm on the global z axis, and to a good approximation they travel with the speed of light. We would need a technology to resolve the geometrical path difference divided by the speed of light to resolve this. That technology doesn't exist yet.
", "votes": null, "replies": [] }, { "id": 322237, "author_name": "msmk00", "author_url": "", "post_date": "05/02/2018 15:42:08", "content": "We do not. Within one event the hits appear simultaneous to the detector.
\n\nTo put the average 6 hits/module/event into perspective: a module is the smallest detector component and can have a surface area between 2x2 cm² and 10x10 cm² (roughly). Each module surface is gridded into cells or pixels that can range in size from 0.05x0.0565 µm² to 0.12x10.8 mm². With 6 hits, only a tiny fraction of the possible cells is active. Separating these different active cells/pixels spatially is therefore not an issue.
", "votes": null, "replies": [] }, { "id": 322846, "author_name": "nimararora", "author_url": "", "post_date": "05/03/2018 19:07:22", "content": "\n\n\nSorting by z-axis works great, thanks!
\n
Wouldn't it be better to sort by distance from origin?
", "votes": null, "replies": [] }, { "id": 322877, "author_name": "lopuhin", "author_url": "", "post_date": "05/03/2018 20:38:52", "content": "\n\n\nWouldn't it be better to sort by distance from origin?
\n
I think no, I tried both ways - it's hard to describe it in words, but the helix is usually aligned with z-axis but the path along the helix can have x and y decreasing faster than z is increasing, so getting closer to origin
", "votes": null, "replies": [] } ] } ], "raw_markdown_by_id": { "321727": "I noticed in all of the data points we have space coordinates but no time coordinates at all. Are we to assume that all of the hits are nearly simultaneous?", "321730": "The current technology is not (yet) at the stage to achieve detectors with a good enough timing resolution such that this could reliably be used. Hence, hit time information is not available.", "321739": "I see, but can we at least assume that the hits are in time sequence order?", "321742": "The particles move from the center of the detector outwards, so - yes, indeed, they are ordered in that sense. However, within the dataset they are ordered like a detector would read them out, module by module.", "321773": "From the detector point-of-view all hits occur at the same time. The time it takes for the particles to move through the detector is much shorter than the time resolution of the detector modules.", "321820": "So, what about the modules that have multiple particles hitting them. Don't we even have information on the order of hits occurring at a single module?", "321823": "I am not a physicist.\n\nThere is a description of the detector around someplace. Think of it as Detector is made up of Modules and a Module is made up of Cells. Some cells are further divided into channels. The data provides data down to the cell/channel level and the energy 'deposited' into that cell. AFAIK the cell can't tell between two particles interacting with the cell or one particle interacting one or more times.", "321939": "Here's the description document:\nhttps://cernbox.cern.ch/index.php/s/tkF9YFCrYu8auWw\n\nIn fact, we simplified the problem: if a cell was hit by two particles (this is an rather rare process) we produce two individual measurements in order to allow you to do a unique assignment of a ``hit_id`` to a ``track_id``. In reality, these channels would merge, but for the sake of this challenge we split them already for you beforehand.", "322011": "> The particles move from the center of the detector outwards, so - yes, indeed, they are ordered in that sense. \n\n@asalzburger By looking at the tracks it seems that it's not always the case, given that the origin of the particle is not exactly at the center. I mean that I think the order of hits the particle took is not the same as hits ordered by distance from the center. I think some way to recover ground truth order would be really useful.", "322013": "Well spotted, Konstantin. Those particles produced not at the interaction region are so-called ``secondaries`` that are created from interactions of ``primary`` particles (the ones from the initial collision) with detector material. As these interactions go, they are roughly following the initial direction, but usually have less hits and lower momentum.", "322015": "The *truth* can be recovered for the training dataset, however, in reality we can not access it -- the particle doesn't leave a position nor momentum at it's creation - otherwise our job would be easy :-)", "322021": "Thanks for clarification Andreas.\n\n> The truth can be recovered for the training dataset\n\nDo you mean it is explicitly present in the train dataset uploaded to Kaggle (I coun't find it)? Or sorting by distance from the origin is the best we have? I understand that it's not available at test time.", "322023": "It is not explicitely stored in the training dataset. Since the particles do not all originate from the origin you should use the absolute distance along the z-axis from the particle vertex for this.", "322033": "You can access the truth position and momentum (=direction) at every hit, from this it should be best determined. We did not *simulate* time information as it is not in reach for us (yet) from a technology standpoint.", "322035": "Sorting by z-axis works great, thanks!", "322229": "> In fact, we simplified the problem: if a cell was hit by two particles (this is an rather rare process) we produce two individual measurements in order to allow you to do a unique assignment of a hit_id to a track_id. In reality, these channels would merge, but for the sake of this challenge we split them already for you beforehand.\n\nWell, I wasn't asking about a cell being hit by two particles, but rather a module being hit by multiple particles. Looking at the statistics -- modules that get hits in an event tend to get on average 6 different particles that hit them, which is clearly not rare. So, to repeat my question -- do we not know the order of these multiple hits on the same module?", "322236": "Sorry, misunderstood. All the particles - as far as we can measure - arrive at one specific module at the same time. \n\nMore info:\nThey come from the same beam-beam interaction which happens mostly within a length of ~5-10 cm on the global z axis, and to a good approximation they travel with the speed of light. We would need a technology to resolve the geometrical path difference divided by the speed of light to resolve this. That technology doesn't exist yet.", "322237": "We do not. Within one event the hits appear simultaneous to the detector.\n\nTo put the average 6 hits/module/event into perspective: a module is the smallest detector component and can have a surface area between 2x2 cm² and 10x10 cm² (roughly). Each module surface is gridded into cells or pixels that can range in size from 0.05x0.0565 µm² to 0.12x10.8 mm². With 6 hits, only a tiny fraction of the possible cells is active. Separating these different active cells/pixels spatially is therefore not an issue.", "322846": "> Sorting by z-axis works great, thanks!\n\nWouldn't it be better to sort by distance from origin?", "322877": "> Wouldn't it be better to sort by distance from origin?\n\nI think no, I tried both ways - it's hard to describe it in words, but the helix is usually aligned with z-axis but the path along the helix can have x and y decreasing faster than z is increasing, so getting closer to origin" }, "source": "meta" }