{
  "id": 619596,
  "title": "a bit stuck - submission failed",
  "url": "/competitions/csiro-biomass/discussion/619596",
  "author_name": "",
  "post_date": "2025-11-14T16:52:22.684129600Z",
  "votes": null,
  "comment_count": 1,
  "views": 0,
  "content": "<p>I have some good submissions. With my latest attempt, I've tested it, it works. Then I submit and get failure. I cannot see in the logs something that I can relate to. Any ideas what can it be?</p>",
  "messages": [
    {
      "id": "3324049",
      "postDate": "11/14/2025 16:52:22",
      "content": "<p>I have some good submissions. With my latest attempt, I've tested it, it works. Then I submit and get failure. I cannot see in the logs something that I can relate to. Any ideas what can it be?</p>",
      "rawMarkdown": "I have some good submissions. With my latest attempt, I've tested it, it works. Then I submit and get failure. I cannot see in the logs something that I can relate to. Any ideas what can it be?",
      "votes": null
    },
    {
      "id": "3324126",
      "postDate": "11/14/2025 18:19:05",
      "content": "<p>You never see the logs for a submission for scoring.  The only log you see is the one generated when the notebook runs against the single provided example test image.   Hiding the actual log is a cheat prevention tool.</p>\n<p>From my experience - when I have a series of successful submissions and than a failure, its often because of a change I made that consumed the available memory or just a plain stupid typo or thinking error.  So recheck those cells that you changed is always a good first step.  How long it takes before the submission fails is often an indicator of stupid (fails fast) or memory (takes a bit of time to fail).</p>\n<p>When a code change review does not help another move I make is to run the notebook and revise the code so it predicts against the train data rather than the test.  That will generate a log that can be useful if the notebook fails during the run.  Most often I run this while in the notebook editor to find the cell that leads to a potential failure.</p>",
      "rawMarkdown": "You never see the logs for a submission for scoring.  The only log you see is the one generated when the notebook runs against the single provided example test image.   Hiding the actual log is a cheat prevention tool.\n\nFrom my experience - when I have a series of successful submissions and than a failure, its often because of a change I made that consumed the available memory or just a plain stupid typo or thinking error.  So recheck those cells that you changed is always a good first step.  How long it takes before the submission fails is often an indicator of stupid (fails fast) or memory (takes a bit of time to fail).\n\nWhen a code change review does not help another move I make is to run the notebook and revise the code so it predicts against the train data rather than the test.  That will generate a log that can be useful if the notebook fails during the run.  Most often I run this while in the notebook editor to find the cell that leads to a potential failure.",
      "votes": null
    }
  ],
  "comments": [
    {
      "id": 3324126,
      "author_name": "pcjimmmy",
      "author_url": "",
      "post_date": "11/14/2025 18:19:05",
      "content": "<p>You never see the logs for a submission for scoring.  The only log you see is the one generated when the notebook runs against the single provided example test image.   Hiding the actual log is a cheat prevention tool.</p>\n<p>From my experience - when I have a series of successful submissions and than a failure, its often because of a change I made that consumed the available memory or just a plain stupid typo or thinking error.  So recheck those cells that you changed is always a good first step.  How long it takes before the submission fails is often an indicator of stupid (fails fast) or memory (takes a bit of time to fail).</p>\n<p>When a code change review does not help another move I make is to run the notebook and revise the code so it predicts against the train data rather than the test.  That will generate a log that can be useful if the notebook fails during the run.  Most often I run this while in the notebook editor to find the cell that leads to a potential failure.</p>",
      "votes": null,
      "replies": []
    }
  ],
  "raw_markdown_by_id": {
    "3324049": "I have some good submissions. With my latest attempt, I've tested it, it works. Then I submit and get failure. I cannot see in the logs something that I can relate to. Any ideas what can it be?",
    "3324126": "You never see the logs for a submission for scoring.  The only log you see is the one generated when the notebook runs against the single provided example test image.   Hiding the actual log is a cheat prevention tool.\n\nFrom my experience - when I have a series of successful submissions and than a failure, its often because of a change I made that consumed the available memory or just a plain stupid typo or thinking error.  So recheck those cells that you changed is always a good first step.  How long it takes before the submission fails is often an indicator of stupid (fails fast) or memory (takes a bit of time to fail).\n\nWhen a code change review does not help another move I make is to run the notebook and revise the code so it predicts against the train data rather than the test.  That will generate a log that can be useful if the notebook fails during the run.  Most often I run this while in the notebook editor to find the cell that leads to a potential failure."
  },
  "source": "meta"
}