1. OpenREM
  2. OpenREM
  3. OpenREM
  4. Issues

Issues

Issue #407 resolved

On a Windows server skin dose maps are not calculated on import when this option is selected

David Platten
created an issue

On Windows the skin dose map data is not calculated on import when this option is selected. The study itself is successfully imported into OpenREM, it is just that the skin dose map data is not calculated and put in the appropriate folder in media.

If you click on the study in OpenREM to view its details then the skin dose map data is successfully calculated. This makes me think that there is nothing wrong with the make_skin_map routine, and that it is working OK with celery.

I suspect that the delay on make_skin_map in rdsr.py is causing the problem, because changing

make_skin_map.delay(g.pk)

to

make_skin_map(g.pk)

solves the problem. Perhaps the delay in the rdsr.py call to make_skin_map is not needed because make_skin_map is already being run as a celery task?

I have tested the above change by importing a fluoro rdsr, and whilst it is importing and the skin dose data being calculated I have imported several DX studies. The fluoro data and skin dose map data were calculated correctly, and I imported nine DX studies at the same time. I think the above is what is needed.

Any thoughts?

Comments (30)

  1. Ed McDonagh

    Off the top of my head, the .delay is what causes it to be a celery task, otherwise make_skin_map will be called directly and you won't exit rdsr.py until the calculation is complete.

  2. David Platten reporter

    Hi Ed McDonagh. Thanks for that. rdsr itself is a celery task, so does it matter if it isn't exited until the skin dose calculations are complete?

    As an aside, is the skin dose map data calculated on import with your Linux system? I'm wondering if this is a Windows issue.

  3. Ed McDonagh

    How are you calling rdsr? If you are calling the openrem_rdsr.py script from a conquest script, that isn't usually the case is it? It does call rdsr as a celery task when the built in QR function is used.

  4. Ed McDonagh

    Awesome, yes please. I need to work out a way of having documentation that can change without a new release, with a reference that can remain the same so that it can be linked to from the installed version...

    Have other OpenREM users hit this? If not, why not?

  5. David Platten reporter

    OK. I'll update the current documentation.

    This seems to only affect the calculation of skin dose map data, so it may be that I'm the only one that has seen this.

  6. David Platten reporter

    Strange. "--pool=solo" isn't working either.

    The "ignore_results=True" addition to "make_skin_map" works fine on my local install. I think that this is the solution, and that there is something else going on with my live system.

  7. David Platten reporter

    Running make_skin_map.delay(some_pk) from a python console on my live system for a study that is already in the database results in the skin dose map data being calculated. I don't understand why this command isn't working when it is called as part of rdsr.py during the import of a DICOM RDSR file.

  8. Ed McDonagh

    Remind me again what your setup is?

    1. Conquest as DICOM Store SCP?
    2. Conquest executes a script?
    3. Script calls python path\to\openrem_rdsr.py path\to\rdsr.dcm?
    4. With no virtualenv?
  9. David Platten reporter

    An update. If I run

    python c:\Python27\Lib\site-packages\openrem\scripts\openrem_rdsr.py c:\ProgramData\OpenREM\test.dcm
    

    the study is imported into OpenREM but no skin dose map data is calculated.

    However, if I run

    python c:\Python27\Lib\site-packages\openrem\remapp\extractors\rdsr.py c:\ProgramData\OpenREM\test.dcm
    

    then the study is imported into OpenREM and the skin dose map data is calculated.

  10. Ed McDonagh

    Why aren't you running python openrem_rdsr.py c:\ProgramData\OpenREM\test.dcm?

    Do you not have the python bin directory on the path? The version in the scripts folder should never be run - the version of that that is copied to the python bin directory (or whatever it's called on Windows) has the shebang line edited on install to suit your environment.

  11. David Platten reporter

    Thanks for the update.

    My earlier post hasn't fixed the issue: the creation of skin dose map data on my system is intermittent...

    When a skin dose map fails my rabbitmq log has

    =WARNING REPORT==== 24-Jun-2016::09:57:30 ===
    closing AMQP connection <0.16945.0> (127.0.0.1:63474 -> 127.0.0.1:5672):
    client unexpectedly closed TCP connection
    

    in it.

  12. David Platten reporter

    I tried using the installed version. Sometimes it works. Sometimes it doesn't (pulling virtual hair out of my bald head at this point...)

    Is skin dose map data calculated on import for your test system?

  13. David Platten reporter

    I've set the heartbeat time to 60s on my rabbitmq install and will see how this affects things. I've done this by setting the contents of the c:\rabbitmq\rabbitmq.config file to:

    [
     {rabbit,
      [%%
       %% Network Connectivity
       %% ====================
       %% Set the default AMQP heartbeat delay (in seconds).
       %%
       {heartbeat, 60}
      ]}
    ].
    
  14. David Platten reporter

    Five cardiac studies have arrived in OpenREM since adding BROKER_TRANSPORT_OPTIONS = {'confirm_publish': True}. All have had skin dose map data calculated automatically on import. I'll check again tomorrow morning.

  15. David Platten reporter

    I have removed the heartbeat configuration from the rabbitmq.config file, but left BROKER_TRANSPORT_OPTIONS = {'confirm_publish': True} in the OpenREM settings.py file. Skin dose map data continues to be calculated on import.

    This is good, as we can control the contents of settings.py, whereas the user would have to alter rabbitmq.config themselves.

  16. Log in to comment