![\"\"](\"https://www.googleapis.com/download/storage/v1/b/kaggle-forum-message-attachments/o/inbox%2F3974868%2F4a8b117472efd756290083dcf0b787c1%2Fimage1.png?generation=1682343676129581&alt=media\")
First of all, I would like to thank the organizers and staff for hosting such a wonderful competition. And thank you to all my wonderful teammates! @anjum48, @allvor, @remekkinas, @wrrosa.
\nCongratulations @anjum48! your promotion to GM!
\nOur code will be available here.
\nThis dataset was really big, and repeatedly doing pandas operations every epoch would have been a waste of CPU cycles (polars does not appear to work with PyTorch data loaders with many workers yet). To address this, I made PyTorch Geometric Data objects for each event and saved them as .pt files which could be loaded during training. This took about 8 hours to create using 32 threads, and required about 1TB of space.
The issue with this was that that 1TB was across 130+ millon tiny files. A Linux partition has a finite number of “index nodes” or inodes, i.e. an index to a certain file. Since these files are so small I ran into my inode limit before I ran out of space on my 2TB drive. As a workaround, I had to spread some of these files across two drives, so heads up for anyone trying to reproduce this method or run my code.
A more efficient way could be to store .pt files that have already been pre-batched which would require fewer files, but then you lose the ability to shuffle every epoch which may/may not make a difference with this much data. I didn’t try the sqlite method suggested by the GraphNet team.
In the context of GNNs, each DOM is considered as a node. Each node was given the following 11 features:
\nMany of the normalisation methods were taken from GraphNet as a starting point, but I altered the scale for time, since time is a very important feature here.
\nFor events with large numbers of hits, to prevent OOM errors, I sampled 256 hits. This can make the process slightly non-deterministic.
\nQE is the quantum efficiency of the photomutipliers in the DOMs. The DeepCore DOMs are quoted to have 35% higher QE than the regular DOMs (Figure 1 of this paper), so QE was set to 1 everywhere, and 1.35 for the lower 50 DOMs in DeepCore. The final QE feature was scaled using (QE - 1.25) / 0.25.
\nScattering and absorption lengths are important to characterise differences in the clarity of the ice. This data is published on page 31 of this paper. A datum depth of 1920 metres was used so that z = (depth - 1920) / 500. The data was resampled to the z values using scipy.interpolate.interp1d. I found that after passing the data though RobustScaler, the scattering and absorption data was near identical, so I only used scattering length.
The two main types of events are track and cascade events. Looking at some of the amazing visualisation tools for example from edguy99, I got the idea that if a node had some understanding where and when the nearest previous hit was, it might help the model differentiate between these two groups. To calculate this for each event, sorted the hits by time, calculated the pairwise distances of all hits, masked any hits from the future and calculated the distance, d, to the nearest previous hit. This was scaled using (d - 0.5) / 0.5. The time delta from the previous hit was also calculated using the same method and scaled using (t - 0.1) / 0.1.
\nI tried to create a flag that could discern whether a hit was caused directly from a track, or some secondary scattering, inspired by section 2.1 of this paper. A side effect of adding this flag was that training was much more stable. The flag is generated as follows:
\nI used 90% - 10% train-validation split, and no cross validation due to the size of the dataset. The split was done by creating 10 bins of log10(n_hits), and then using StratifiedKFold using 10 splits.
I used the DirectionReconstructionWithKappa task directly from GraphNet, meaning that an embedding (e.g. shape of 128) will be projected to a shape of 4 (x, y, z, kappa)
I used the following 3 architectures. All validation scores are with 6x TTA applied
\nGraphNet/DynEdge - Val = 0.98501
\nGPS - Val = 0.98945*
\nGravNet - Val = 0.98519
The average of these 3 models gave a 0.982 LB score.
\nThe GraphNet/DynEdge model had very little modfification, other than changing to GELU activations.
\nGPS & GravNet used 8 blocks and you can find the exact architectures for both in the code here.
\n*GPS was the most powerful model, but also slowest to train being a transformer type model (roughly 11 hours/epoch on my machine). I managed to train a model which achieved a validation score of 0.98XX but was too late to include in our final submission.
\nI used VonMisesFisher3DLoss + (1 - CosineSimilarity) as the final loss function, since cosine similarity is a nice proxy for mean angular error. For CosineSimilarity I transformed the target azimuth & zenith values to cartesian coordinates.
\nThis performed much better than separate losses for azimuth (VMF2D) & zenith (MSE) which I the route I initially went down.
\nI centered the data on string 35 (the DeepCore string) and rotated about the z-axis in 60 degree steps. This didn’t actually improve validation performance but did have the benefit of making the models rotationally invariant so that I could take advantage of the detector symmetry and apply a 6x test time augmentation (TTA). This often improved scores by 0.002-0.003.
\nCircular mean
\nTBC
\nAll my code will be available here soon: https://github.com/Anjum48/icecube-neutrinos-in-deep-ice
\nBefore the team merge, I created LSTM and GraphNet models. After the team merge, I focused on GraphNet because Remek's LSTM model was superior to mine. I used graphnet (https://github.com/graphnet-team/graphnet) as a baseline and made several changes to improve its accuracy. I list below some of the experiments I performed that worked(There are tons of things that didn't work)
\nThe ensemble of models(1st and 2nd) created above gave public LB 0.995669, private LB 0.996550
\nFor LSTM training we used the attitude proposed by Robin Smits (@rsmits) with some improvements.
\nWe added more LSTM/GRU layers (4 GRU/LSTM) - more and less than 4 layers was not better in our experiments.
We added ice transparency as additional features (we used both features – transparency and absorption).
We redesigned the training loop to train models on all batches – we can train models on different parts of DS (from one batch to all DS in one epoch).
We checked many hypotheses (for part of them weight and biases Swipe tool was used):
\nTraining was divided into three parts scheduling LR:
\nThings did not improve our score:
\nAdditional tools:
\nFor my (Remek) experiment I use (in first part of competition) ZbyHP Z4 with 2xA5000 but then HP sent me ZbyHP Z8 workstation with 2x Intel Xeon CPU and Nvidia A6000 GPU. Personally I can say that this help me to establish fast experimentation pipeline. I was able to process dataset files very fast. Having A6000 gave me possibility to train models on bigger batch size. Thank HP for supporting my work.
\nMy final words - we set up a great team in my opinion - each of us was responsible for part of the solution, we discussed a lot but there was no “my is better”. Although we worked together for the first time, I had the impression that we had known each other forever. Great team, great result! Thank you guys for having the opportunity to learn from great AI guys.
\nMy main contribution to this competition was the development of methods for blending my teammates’ solutions. Analysis of the different types of solutions (GraphNet, LSTM etc.) showed that they have different efficiency at different predicted zeniths and azimuths values (zenith mainly). So I changed my initial \"constant weight\" approach to a \"bins\" approach.
\nThe method consists in splitting the predicted zenith values into 10 bins of equal width. Thus, when combining two solutions, we get 100 bins in total. The value of 10 is configurable, but experiments showed it to be close to optimal.
After that, the blending weight for the zenith was found in each bin and the blending weight for the azimuth was found. The blending of predicted zenith values was done by a simple linear combination. Blending the azimuth values was a little more complicated, due to the possible transition through 2*pi. Therefore, to begin with, the difference in the predicted azimuths in the two solutions was calculated and the direction of the second value relative to the first value.
\nWeights fitting was carried out on a sample of training data close in size to the test data (5 batches with 1M events).
Several approaches to improve this blending method were also tested. In particular, the use of GBDT.
\nOne of these approaches was an attempt to classify events into “simple” and “complex” ones (inspired by the kernel https://www.kaggle.com/code/tatelarkin/neutrino-event-type-classifier-auc-score-0-93).
\nExperiments have shown that some types of neural networks are better at handling simple events, while other types are better at handling complex events. If we could accurately determine the type of each event, this would greatly improve the competition metric. A model was built, the efficiency of which in events classifying was at the level of the public kernel (AUС 0.93), but this was not enough to get a noticeable improvement in the blend quality.
\nSeveral other models of classification (binary variable - which of the two neural networks better predicts a given event) and regression (target variable - the difference in competition metrics from two neural networks for a given event) were also trained. Unfortunately, all these approaches showed only a minor improvement in the result (fourth decimal place), but they were very overfitting-sensitive.
\nLater, my method was significantly improved by Wojtek Rosa. Therefore, it was his approach that was used in the final submissions, which he describes in more detail in his part. In particular, I would like to note his brilliant idea of using a Decision Tree model to build blending bins.
\nThank you competition host for exciting competition IceCube!
\nAlso thank you my Teammates - once again congrats for their prizes, GM titles and great solutions.
\nMy part was about blending.
\nI used batch_ids 1-5 for evaluation and adjusting parameters, later I used batch_ids 655+ only for evaluation purposes.
\nWhen I joined Remek&Alvor team, we have great LSTM solution, public Graphnet, and amazing blend technique:
():\n s[] = np.(s[] - s[])\n s[] = np.where(\n s[] < np.pi,\n np.sign(s[] - s[]),\n -np.sign(s[] - s[])\n )\n N = \n s[] = (N*np.floor(N*s[]/np.pi) + np.floor(N*s[]/np.pi)).astype()\nand minimize score for each bin, finding best qu, alpha such as:
\ns0[] = s0[] + alpha * s0[] * s0[]\ns0[] = (-qu) * s0[] + qu * s0[]\nI realize, that compared to simple/public vector weight ensembling this method is much better.
\nI tried to improve score with greater N values but this leads me to overfit.
\nAfter this, I managed to improve the score, by creating bins using Regression Trees with target = score_1 - score_2 and features:
cls = [,,,,,, ,,,,,,\n ,,,]\nwhere direction_% are from Isamu submission, zenith_3 is from crazy quick and clean 1.183 Robert linear solution. I tried many different features directly from event, but
\nThe simplicity of Decision Tree Regressor gave us (almost) full control of N bins for adjustment allvors parameters qu and alpha:
regr_1 = DecisionTreeRegressor(max_depth=, min_samples_leaf=, min_samples_split=)\ns[] = regr_1.predict(s[cls])\ns[] = (s[],).astype()\nUsing DecissionTrees gave us 0.0027 boost both with local score and LB. I tried other methods of blending such as MLP or LGBM without success.
\nLater on, I also slightly modified adjusting loop, for finding full linear combination of zenith_1 and zenith_2:
s0[] = s0[] + alpha * s0[] * s0[]\ns0[] = ru * s0[] + qu * s0[]\nIt takes much more computation to find ru and qu, but that gives us additional 0.001 improvement.
\nOur final blend consist:
\nIsamu solution .995 -> Remek LSTM 1.002 -> datasaurus Graphnet .982 -> Robert 1.183
\nlocal score 0.9774692 Public LB 0.975545, Private LB 0.97658
Ground truth zenith (x-axis) vs score (y-axis) - ‘error triangle’ visible:
\n![\"\"](\"https://www.googleapis.com/download/storage/v1/b/kaggle-forum-message-attachments/o/inbox%2F3974868%2F2ee6d7032191782027e45522daff9081%2Fimage2.png?generation=1682343631946316&alt=media\")
![\"\"](\"https://www.googleapis.com/download/storage/v1/b/kaggle-forum-message-attachments/o/inbox%2F3974868%2F7fde090be1100c83a09f045fbf57f5fd%2Fimage3.png?generation=1682343415933098&alt=media\")
First of all, I would like to thank the organizers and staff for hosting such a wonderful competition. And thank you to all my wonderful teammates! @anjum48, @allvor, @remekkinas, @wrrosa.
\nCongratulations @anjum48! your promotion to GM!
\nOur code will be available here.
\nThis dataset was really big, and repeatedly doing pandas operations every epoch would have been a waste of CPU cycles (polars does not appear to work with PyTorch data loaders with many workers yet). To address this, I made PyTorch Geometric Data objects for each event and saved them as .pt files which could be loaded during training. This took about 8 hours to create using 32 threads, and required about 1TB of space.
The issue with this was that that 1TB was across 130+ millon tiny files. A Linux partition has a finite number of “index nodes” or inodes, i.e. an index to a certain file. Since these files are so small I ran into my inode limit before I ran out of space on my 2TB drive. As a workaround, I had to spread some of these files across two drives, so heads up for anyone trying to reproduce this method or run my code.
A more efficient way could be to store .pt files that have already been pre-batched which would require fewer files, but then you lose the ability to shuffle every epoch which may/may not make a difference with this much data. I didn’t try the sqlite method suggested by the GraphNet team.
In the context of GNNs, each DOM is considered as a node. Each node was given the following 11 features:
\nMany of the normalisation methods were taken from GraphNet as a starting point, but I altered the scale for time, since time is a very important feature here.
\nFor events with large numbers of hits, to prevent OOM errors, I sampled 256 hits. This can make the process slightly non-deterministic.
\nQE is the quantum efficiency of the photomutipliers in the DOMs. The DeepCore DOMs are quoted to have 35% higher QE than the regular DOMs (Figure 1 of this paper), so QE was set to 1 everywhere, and 1.35 for the lower 50 DOMs in DeepCore. The final QE feature was scaled using (QE - 1.25) / 0.25.
\nScattering and absorption lengths are important to characterise differences in the clarity of the ice. This data is published on page 31 of this paper. A datum depth of 1920 metres was used so that z = (depth - 1920) / 500. The data was resampled to the z values using scipy.interpolate.interp1d. I found that after passing the data though RobustScaler, the scattering and absorption data was near identical, so I only used scattering length.
The two main types of events are track and cascade events. Looking at some of the amazing visualisation tools for example from edguy99, I got the idea that if a node had some understanding where and when the nearest previous hit was, it might help the model differentiate between these two groups. To calculate this for each event, sorted the hits by time, calculated the pairwise distances of all hits, masked any hits from the future and calculated the distance, d, to the nearest previous hit. This was scaled using (d - 0.5) / 0.5. The time delta from the previous hit was also calculated using the same method and scaled using (t - 0.1) / 0.1.
\nI tried to create a flag that could discern whether a hit was caused directly from a track, or some secondary scattering, inspired by section 2.1 of this paper. A side effect of adding this flag was that training was much more stable. The flag is generated as follows:
\nI used 90% - 10% train-validation split, and no cross validation due to the size of the dataset. The split was done by creating 10 bins of log10(n_hits), and then using StratifiedKFold using 10 splits.
I used the DirectionReconstructionWithKappa task directly from GraphNet, meaning that an embedding (e.g. shape of 128) will be projected to a shape of 4 (x, y, z, kappa)
I used the following 3 architectures. All validation scores are with 6x TTA applied
\nGraphNet/DynEdge - Val = 0.98501
\nGPS - Val = 0.98945*
\nGravNet - Val = 0.98519
The average of these 3 models gave a 0.982 LB score.
\nThe GraphNet/DynEdge model had very little modfification, other than changing to GELU activations.
\nGPS & GravNet used 8 blocks and you can find the exact architectures for both in the code here.
\n*GPS was the most powerful model, but also slowest to train being a transformer type model (roughly 11 hours/epoch on my machine). I managed to train a model which achieved a validation score of 0.98XX but was too late to include in our final submission.
\nI used VonMisesFisher3DLoss + (1 - CosineSimilarity) as the final loss function, since cosine similarity is a nice proxy for mean angular error. For CosineSimilarity I transformed the target azimuth & zenith values to cartesian coordinates.
\nThis performed much better than separate losses for azimuth (VMF2D) & zenith (MSE) which I the route I initially went down.
\nI centered the data on string 35 (the DeepCore string) and rotated about the z-axis in 60 degree steps. This didn’t actually improve validation performance but did have the benefit of making the models rotationally invariant so that I could take advantage of the detector symmetry and apply a 6x test time augmentation (TTA). This often improved scores by 0.002-0.003.
\nCircular mean
\nTBC
\nAll my code will be available here soon: https://github.com/Anjum48/icecube-neutrinos-in-deep-ice
\nBefore the team merge, I created LSTM and GraphNet models. After the team merge, I focused on GraphNet because Remek's LSTM model was superior to mine. I used graphnet (https://github.com/graphnet-team/graphnet) as a baseline and made several changes to improve its accuracy. I list below some of the experiments I performed that worked(There are tons of things that didn't work)
\nThe ensemble of models(1st and 2nd) created above gave public LB 0.995669, private LB 0.996550
\nFor LSTM training we used the attitude proposed by Robin Smits (@rsmits) with some improvements.
\nWe added more LSTM/GRU layers (4 GRU/LSTM) - more and less than 4 layers was not better in our experiments.
We added ice transparency as additional features (we used both features – transparency and absorption).
We redesigned the training loop to train models on all batches – we can train models on different parts of DS (from one batch to all DS in one epoch).
We checked many hypotheses (for part of them weight and biases Swipe tool was used):
\nTraining was divided into three parts scheduling LR:
\nThings did not improve our score:
\nAdditional tools:
\nFor my (Remek) experiment I use (in first part of competition) ZbyHP Z4 with 2xA5000 but then HP sent me ZbyHP Z8 workstation with 2x Intel Xeon CPU and Nvidia A6000 GPU. Personally I can say that this help me to establish fast experimentation pipeline. I was able to process dataset files very fast. Having A6000 gave me possibility to train models on bigger batch size. Thank HP for supporting my work.
\nMy final words - we set up a great team in my opinion - each of us was responsible for part of the solution, we discussed a lot but there was no “my is better”. Although we worked together for the first time, I had the impression that we had known each other forever. Great team, great result! Thank you guys for having the opportunity to learn from great AI guys.
\nMy main contribution to this competition was the development of methods for blending my teammates’ solutions. Analysis of the different types of solutions (GraphNet, LSTM etc.) showed that they have different efficiency at different predicted zeniths and azimuths values (zenith mainly). So I changed my initial \"constant weight\" approach to a \"bins\" approach.
\nThe method consists in splitting the predicted zenith values into 10 bins of equal width. Thus, when combining two solutions, we get 100 bins in total. The value of 10 is configurable, but experiments showed it to be close to optimal.
After that, the blending weight for the zenith was found in each bin and the blending weight for the azimuth was found. The blending of predicted zenith values was done by a simple linear combination. Blending the azimuth values was a little more complicated, due to the possible transition through 2*pi. Therefore, to begin with, the difference in the predicted azimuths in the two solutions was calculated and the direction of the second value relative to the first value.
\nWeights fitting was carried out on a sample of training data close in size to the test data (5 batches with 1M events).
Several approaches to improve this blending method were also tested. In particular, the use of GBDT.
\nOne of these approaches was an attempt to classify events into “simple” and “complex” ones (inspired by the kernel https://www.kaggle.com/code/tatelarkin/neutrino-event-type-classifier-auc-score-0-93).
\nExperiments have shown that some types of neural networks are better at handling simple events, while other types are better at handling complex events. If we could accurately determine the type of each event, this would greatly improve the competition metric. A model was built, the efficiency of which in events classifying was at the level of the public kernel (AUС 0.93), but this was not enough to get a noticeable improvement in the blend quality.
\nSeveral other models of classification (binary variable - which of the two neural networks better predicts a given event) and regression (target variable - the difference in competition metrics from two neural networks for a given event) were also trained. Unfortunately, all these approaches showed only a minor improvement in the result (fourth decimal place), but they were very overfitting-sensitive.
\nLater, my method was significantly improved by Wojtek Rosa. Therefore, it was his approach that was used in the final submissions, which he describes in more detail in his part. In particular, I would like to note his brilliant idea of using a Decision Tree model to build blending bins.
\nThank you competition host for exciting competition IceCube!
\nAlso thank you my Teammates - once again congrats for their prizes, GM titles and great solutions.
\nMy part was about blending.
\nI used batch_ids 1-5 for evaluation and adjusting parameters, later I used batch_ids 655+ only for evaluation purposes.
\nWhen I joined Remek&Alvor team, we have great LSTM solution, public Graphnet, and amazing blend technique:
():\n s[] = np.(s[] - s[])\n s[] = np.where(\n s[] < np.pi,\n np.sign(s[] - s[]),\n -np.sign(s[] - s[])\n )\n N = \n s[] = (N*np.floor(N*s[]/np.pi) + np.floor(N*s[]/np.pi)).astype()\nand minimize score for each bin, finding best qu, alpha such as:
\ns0[] = s0[] + alpha * s0[] * s0[]\ns0[] = (-qu) * s0[] + qu * s0[]\nI realize, that compared to simple/public vector weight ensembling this method is much better.
\nI tried to improve score with greater N values but this leads me to overfit.
\nAfter this, I managed to improve the score, by creating bins using Regression Trees with target = score_1 - score_2 and features:
cls = [,,,,,, ,,,,,,\n ,,,]\nwhere direction_% are from Isamu submission, zenith_3 is from crazy quick and clean 1.183 Robert linear solution. I tried many different features directly from event, but
\nThe simplicity of Decision Tree Regressor gave us (almost) full control of N bins for adjustment allvors parameters qu and alpha:
regr_1 = DecisionTreeRegressor(max_depth=, min_samples_leaf=, min_samples_split=)\ns[] = regr_1.predict(s[cls])\ns[] = (s[],).astype()\nUsing DecissionTrees gave us 0.0027 boost both with local score and LB. I tried other methods of blending such as MLP or LGBM without success.
\nLater on, I also slightly modified adjusting loop, for finding full linear combination of zenith_1 and zenith_2:
s0[] = s0[] + alpha * s0[] * s0[]\ns0[] = ru * s0[] + qu * s0[]\nIt takes much more computation to find ru and qu, but that gives us additional 0.001 improvement.
\nOur final blend consist:
\nIsamu solution .995 -> Remek LSTM 1.002 -> datasaurus Graphnet .982 -> Robert 1.183
\nlocal score 0.9774692 Public LB 0.975545, Private LB 0.97658
Ground truth zenith (x-axis) vs score (y-axis) - ‘error triangle’ visible:
\n
This topic is very informative and clearly explained. I learned a lot from reading this post. You have done a great job of presenting the concepts in a simple and engaging way. I appreciate your effort and knowledge.
\nI am going to bookmark this post for future reference. This is a valuable resource that I want to revisit and review. Thank you for sharing this with us. You and your teammates are awesome @yamsam! 😊
", "rawMarkdown": "This topic is very informative and clearly explained. I learned a lot from reading this post. You have done a great job of presenting the concepts in a simple and engaging way. I appreciate your effort and knowledge.\n\nI am going to bookmark this post for future reference. This is a valuable resource that I want to revisit and review. Thank you for sharing this with us. You and your teammates are awesome @yamsam! 😊", "votes": 1 }, { "id": 2234866, "postDate": "2023-04-25T14:37:50.237Z", "content": "Congratulations!
\nI really wonder how you could find good models such as GPS and GravNet.
\nI also searched about models but could not find good models.
@anjum48's notebook on GNN was very helpful. Thank you very much!
", "rawMarkdown": "Congratulations!\nI really wonder how you could find good models such as GPS and GravNet.\nI also searched about models but could not find good models.\n\n@anjum48's notebook on GNN was very helpful. Thank you very much!", "votes": 2 }, { "id": 2233975, "postDate": "2023-04-24T18:30:23.113Z", "content": "@yamsam thanks for the detailed topic! Enjoyed reading
", "rawMarkdown": "@yamsam thanks for the detailed topic! Enjoyed reading", "votes": 2 }, { "id": 2941059, "postDate": "2024-07-30T16:15:08.530Z", "content": "Congrats to @yamsam and the team for the impressive 8th place finish in the IceCube Neutrino Observatory competition! Your approach to preprocessing, model architectures, and blending is truly commendable. The detailed insights on handling large datasets and optimizing model performance are incredibly valuable. A special shoutout to @anjum48 for the GM promotion and @allvor, @remekkinas, and @wrrosa for their contributions. Looking forward to exploring the code and learning more from your solutions.
\nThanks for sharing!
Congratulations on the achievement!
", "rawMarkdown": "Congratulations on the achievement!" }, { "id": 2363820, "postDate": "2023-07-29T00:51:03.970Z", "content": "Congratulations！Amazing work with informative figure and clear explaination!
\nThanks for your sharing! @yamsam
This topic is very informative and clearly explained. I learned a lot from reading this post. You have done a great job of presenting the concepts in a simple and engaging way. I appreciate your effort and knowledge.
\nI am going to bookmark this post for future reference. This is a valuable resource that I want to revisit and review. Thank you for sharing this with us. You and your teammates are awesome @yamsam! 😊
", "votes": 1, "replies": [] }, { "id": 2234866, "author_name": "moto", "author_url": "", "post_date": "2023-04-25T14:37:50.237000", "content": "Congratulations!
\nI really wonder how you could find good models such as GPS and GravNet.
\nI also searched about models but could not find good models.
@anjum48's notebook on GNN was very helpful. Thank you very much!
", "votes": 2, "replies": [] }, { "id": 2233975, "author_name": "serangu", "author_url": "", "post_date": "2023-04-24T18:30:23.113000", "content": "@yamsam thanks for the detailed topic! Enjoyed reading
", "votes": 2, "replies": [] }, { "id": 2941059, "author_name": "", "author_url": "", "post_date": "2024-07-30T16:15:08.530000", "content": "Congrats to @yamsam and the team for the impressive 8th place finish in the IceCube Neutrino Observatory competition! Your approach to preprocessing, model architectures, and blending is truly commendable. The detailed insights on handling large datasets and optimizing model performance are incredibly valuable. A special shoutout to @anjum48 for the GM promotion and @allvor, @remekkinas, and @wrrosa for their contributions. Looking forward to exploring the code and learning more from your solutions.
\nThanks for sharing!
Congratulations on the achievement!
", "votes": 0, "replies": [] }, { "id": 2363820, "author_name": "", "author_url": "", "post_date": "2023-07-29T00:51:03.970000", "content": "Congratulations！Amazing work with informative figure and clear explaination!
\nThanks for your sharing! @yamsam