Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

ValueError: block already occupied #368

Closed
gnthibault opened this issue May 8, 2018 · 13 comments · May be fixed by #550
Closed

ValueError: block already occupied #368

gnthibault opened this issue May 8, 2018 · 13 comments · May be fixed by #550

Comments

@gnthibault
Copy link

Dear developer of Astroplan,

Thank you for this software, the capabilities are really interesting.
I am trying to leverage the power of astroplan into one of my project, unfortunately, I had trouble trying to integrate something very similar to this tutorial in my code:
http://astroplan.readthedocs.io/en/latest/tutorials/scheduling.html

I have not been able to generate a MWE yet, because my code includes sensitive informations, like gps coordinates. But this error may be simple to solve, here is why I reproduce the call stack hereafter:

Traceback (most recent call last):

  File "./ObservationPlanner/ObservationPlanner.py", line 108, in gen_schedule
    self.schedule = prior_scheduler(obs_blocks, priority_schedule)
  File "/home/user/anaconda3/lib/python3.6/site-packages/astroplan/scheduling.py", line 542, in __call__
    schedule = self._make_schedule(copied_blocks)
  File "/home/user/anaconda3/lib/python3.6/site-packages/astroplan/scheduling.py", line 791, in _make_schedule
    _is_scheduled = self.attempt_insert_block(b, new_start_time, start_time_idx)
  File "/home/user/anaconda3/lib/python3.6/site-packages/astroplan/scheduling.py", line 821, in attempt_insert_block
    raise ValueError('block already occupied')
ValueError: block already occupied

How can I debug this ? Thank you in advance for your help
@bmorris3
Copy link
Contributor

bmorris3 commented May 8, 2018

That error occurs when you try to schedule an observing block into the same time slot as another observing block, which has already been scheduled. Is it possible that you're calling the scheduler twice on the same schedule?

@gnthibault
Copy link
Author

Thank you very much for your answer.
However, there is something I might not really understand about wether two blocks are in the same time slot or not.

Here is a MWE that summarize what I am trying to do, and that exhibit the error:


from astroplan import Observer
from astroplan import FixedTarget
from astropy.time import Time
from astroplan.constraints import AtNightConstraint, AirmassConstraint
from astroplan import ObservingBlock
from astroplan.constraints import TimeConstraint
from astropy import units as u
from astropy.coordinates import SkyCoord
from astroplan.constraints import AtNightConstraint, AirmassConstraint
from astroplan.scheduling import Transitioner
from astroplan.scheduling import Schedule
from astroplan.scheduling import PriorityScheduler

apo = Observer.at_site('apo')
blocks = []
global_constraints = [AirmassConstraint(max = 3, boolean_constraint = False),
                      AtNightConstraint.twilight_civil()]
target = FixedTarget(SkyCoord(70.1*u.deg, 47.3*u.deg))

b = ObservingBlock.from_exposures(target, 0, 2*u.second, 3, 1*u.second,
                                    configuration = {'filter': 'Luminance'})
blocks.append(b)
target = FixedTarget(SkyCoord(73.5*u.deg, 48.4*u.deg))
b = ObservingBlock.from_exposures(target, 0, 2*u.second, 3, 1*u.second,
                                    configuration = {'filter': 'Luminance'})
blocks.append(b)

slew_rate = 1.5*u.deg/u.second
transitioner = Transitioner(slew_rate,
                            {'filter':{'default': 10*u.second}})


prior_scheduler = PriorityScheduler(constraints = global_constraints,
                                    observer = apo,
                                    transitioner = transitioner)
now = Time('2018-05-08 16:37:59.926890')
noon_after = Time('2018-05-09 10:00:00')
priority_schedule = Schedule(now, noon_after)
prior_scheduler(blocks, priority_schedule)

Maybe you could tell me what is wrong with this program.
Thank you very much for your valuable help

@bmorris3
Copy link
Contributor

bmorris3 commented May 9, 2018

@gnthibault – it seems to me that the problem has to do with how short your observing blocks are. Do you really intend to take 3x 2 second exposures of each target? If you increase the exposure length to something more typical (100 seconds, for example), the script works without error.

@gnthibault
Copy link
Author

gnthibault commented May 9, 2018 •
edited
Loading

Awesome, it worked!, indeed, it is true that I usually use much more acquisitions than 3,
although the exposure time can vary from less than 1 seconde to few minutes
Using ten times more exposures (count) yield a working example now.
However it was convenient for me to set up testing scenarii
with few number of exposure/low exposure time, maybe there is a way of refining
the time grid used for scheduling exposures ?.

Regarding the scheduling itself, I found this feature really awesome, exactly what I
was looking for.
However, playing around with this feature, I noticed 2 things, that made me ask question
about the score based scheduling policy:

-If I schedule the above program with 10 time the number of exposure each time,
I end up with this schedule:

<Table length=7>
target         start time (UTC)         end time (UTC)      duration (minutes)   ra   dec       configuration     
object              str23                   str23                float64       str32 str32          object        
--------------- ----------------------- ----------------------- ------------------- ----- ----- -----------------------
None 2018-05-09 02:17:19.948 2018-05-09 02:18:59.948  1.6666666666665542  70.1  47.3 {'filter': 'Luminance'}
TransitionBlock 2018-05-09 02:18:59.948 2018-05-09 02:19:19.948 0.33333333333327886                                  []
None 2018-05-09 02:19:19.948 2018-05-09 02:20:59.948   1.666666666666714  73.5  48.4 {'filter': 'Luminance'}
TransitionBlock 2018-05-09 02:20:59.948 2018-05-09 02:21:19.948 0.33333333333327886                                  []
None 2018-05-09 02:21:19.948 2018-05-09 02:22:59.948   1.666666666666714  70.1  47.3 {'filter': 'Luminance'}
TransitionBlock 2018-05-09 02:22:59.948 2018-05-09 02:23:19.948 0.33333333333327886                                  []
None 2018-05-09 02:23:19.948 2018-05-09 02:24:59.948   1.666666666666714  73.5  48.4 {'filter': 'Luminance'}

Can you confirm that the scheduler interleaved the 2 target blocks into 4 slots
in order to optimize the overall score of each target ?
For instance in this case, observation was splitted into 4 slots instead of 2,
yielding 3 transitions instead of 1 in order to favor the airmass cost for observations ?

If this is the case, it is truly awesome!

-Second question, I tried to schedule a more complex acquisition scheme with only 1
target, and 2 sets of L+R+G+B blocks.

I thought that pairs of L-L, R-R G-G and B-B would be concatenated in order to save
one filter transition (set to default 10 seconds), however they don't:

     target         start time (UTC)         end time (UTC)      duration (minutes)     ra       dec           configuration        
--------------- ----------------------- ----------------------- ------------------- --------- --------- ----------------------------
           None 2018-05-09 19:28:16.521 2018-05-09 19:29:56.521  1.6666666666665542 70.839125 47.357167      {'filter': 'Luminance'}
TransitionBlock 2018-05-09 19:29:56.521 2018-05-09 19:30:16.521 0.33333333333327886                      ['filter:Luminance to Red']
           None 2018-05-09 19:30:16.521 2018-05-09 19:32:16.521   1.999999999999993 70.839125 47.357167            {'filter': 'Red'}
TransitionBlock 2018-05-09 19:32:16.521 2018-05-09 19:32:36.521 0.33333333333327886                          ['filter:Red to Green']
           None 2018-05-09 19:32:36.521 2018-05-09 19:34:36.521   1.999999999999993 70.839125 47.357167          {'filter': 'Green'}
TransitionBlock 2018-05-09 19:34:36.521 2018-05-09 19:34:56.521 0.33333333333327886                         ['filter:Green to Blue']
           None 2018-05-09 19:34:56.521 2018-05-09 19:36:56.521   1.999999999999993 70.839125 47.357167           {'filter': 'Blue'}
TransitionBlock 2018-05-09 19:36:56.521 2018-05-09 19:37:16.521 0.33333333333327886                     ['filter:Blue to Luminance']
           None 2018-05-09 19:37:16.521 2018-05-09 19:38:56.521   1.666666666666714 70.839125 47.357167      {'filter': 'Luminance'}
TransitionBlock 2018-05-09 19:38:56.521 2018-05-09 19:39:16.521 0.33333333333327886                      ['filter:Luminance to Red']
           None 2018-05-09 19:39:16.521 2018-05-09 19:41:16.521   1.999999999999993 70.839125 47.357167            {'filter': 'Red'}
TransitionBlock 2018-05-09 19:41:16.521 2018-05-09 19:41:36.521 0.33333333333327886                          ['filter:Red to Green']
           None 2018-05-09 19:41:36.521 2018-05-09 19:43:36.521   1.999999999999993 70.839125 47.357167          {'filter': 'Green'}
TransitionBlock 2018-05-09 19:43:36.521 2018-05-09 19:43:56.521 0.33333333333327886                         ['filter:Green to Blue']
           None 2018-05-09 19:43:56.521 2018-05-09 19:45:56.521   1.999999999999993 70.839125 47.357167           {'filter': 'Blue'}

Do you think that the splitting also result from the optimization of the overall airmass for each filter ?
I tested increasing priority of Luminance and Red exposure to 0, and every other filter to 1, and I got:

     target         start time (UTC)         end time (UTC)      duration (minutes)     ra       dec           configuration       
--------------- ----------------------- ----------------------- ------------------- --------- --------- ---------------------------
           None 2018-05-09 19:28:08.472 2018-05-09 19:29:48.472  1.6666666666665542 70.839125 47.357167     {'filter': 'Luminance'}
TransitionBlock 2018-05-09 19:29:48.472 2018-05-09 19:30:08.472 0.33333333333327886                     ['filter:Luminance to Red']
           None 2018-05-09 19:30:08.472 2018-05-09 19:32:08.472   1.999999999999993 70.839125 47.357167           {'filter': 'Red'}
TransitionBlock 2018-05-09 19:32:08.472 2018-05-09 19:32:28.472 0.33333333333327886                     ['filter:Red to Luminance']
           None 2018-05-09 19:32:28.472 2018-05-09 19:34:08.472   1.666666666666714 70.839125 47.357167     {'filter': 'Luminance'}
TransitionBlock 2018-05-09 19:34:08.472 2018-05-09 19:34:28.472 0.33333333333327886                     ['filter:Luminance to Red']
           None 2018-05-09 19:34:28.472 2018-05-09 19:36:28.472   1.999999999999993 70.839125 47.357167           {'filter': 'Red'}
TransitionBlock 2018-05-09 19:36:28.472 2018-05-09 19:36:48.472 0.33333333333327886                         ['filter:Red to Green']
           None 2018-05-09 19:36:48.472 2018-05-09 19:38:48.472   1.999999999999993 70.839125 47.357167         {'filter': 'Green'}
TransitionBlock 2018-05-09 19:38:48.472 2018-05-09 19:39:08.472 0.33333333333327886                        ['filter:Green to Blue']
           None 2018-05-09 19:39:08.472 2018-05-09 19:41:08.472   1.999999999999993 70.839125 47.357167          {'filter': 'Blue'}
TransitionBlock 2018-05-09 19:41:08.472 2018-05-09 19:41:28.472 0.33333333333327886                        ['filter:Blue to Green']
           None 2018-05-09 19:41:28.472 2018-05-09 19:43:28.472   1.999999999999993 70.839125 47.357167         {'filter': 'Green'}
TransitionBlock 2018-05-09 19:43:28.472 2018-05-09 19:43:48.472 0.33333333333327886                        ['filter:Green to Blue']
           None 2018-05-09 19:43:48.472 2018-05-09 19:45:48.472   1.999999999999993 70.839125 47.357167          {'filter': 'Blue'}

I find it weird that the optimizer keeps Luminance and Red images separated by a transition instead of merging the blocks with the
same filter in order to save on transition. Is there something I am doing wrong here ?

Thank you in advance for your help, this python module looks really promising.

@bmorris3
Copy link
Contributor

bmorris3 commented May 9, 2018 •
edited
Loading

I think the scheduling plots can be really instructive when trying to understand why the scheduler makes its decisions –– have you tried plotting the resulting schedules to see how the airmass varies across for each schedule? see here for examples in the docs

@gnthibault
Copy link
Author

gnthibault commented May 9, 2018 •
edited
Loading

Thank you, I solved some of my issues, although I have been slightly surpsied by some behaviour:
-It looks like although a block is made of multiple acquisitions, it cannot be automatically splitted into smaller blocks
-it means that telescope can be under utilized if the B session from the R/G/B set is too long for instance, it wont be scheduled at all
-Scheduler does not split blocks of smaller priority so that they can be scheduled before and after the optimal airmass slot

Of course, I know that optimal scheduling tend to end-up being NPHard problems, so I won't be too hard on the criticism.

Looks at the nice plots I have been able to generate thanks to your astropy/astroplan/matplotlib:

figure_0
figure_1

No I just need to implement my own constraint for defining my local horizon (in green on the polar grid figure).

@bmorris3
Copy link
Contributor

We intentionally define an observing block as a "minimum schedulable unit of observations" – see our Terminology page for the precise definitions of each term.

If you'd like the ability to split up a block into smaller segments, you should initialize multiple ObservingBlock objects, each containing the segments of the observation.

@gnthibault
Copy link
Author

gnthibault commented May 14, 2018 •
edited
Loading

Thank you very much for your feedback. I changed my calls to astroplan, so that each observing block is no more longer than 300 seconds now.

Now I still need to implement my own constraint, following the guideline you give here:http://astroplan.readthedocs.io/en/latest/tutorials/constraints.html for my local horizon.

@bmorris3
Copy link
Contributor

It looks like this issue has been resolved, feel free to re-open it if I'm incorrect.

@amanda-pagul
Copy link

Hello @bmorris3! I have been trying to use astroplan to schedule some observations and am getting the same "ValueError: block already occupied" error as above. You mentioned that it may be because the observation length is short (in my case, a bright star, so I want <1sec exposures!). Is there any way around this issue with short exposures?

Thanks in advance! And Happy New Year! :)

@bmorris3
Copy link
Contributor

bmorris3 commented Jan 3, 2020

Hi @amendochka! Happy New Year to you as well.

Is it possible that your observations might naturally group into larger blocks? For example, if you will be taking <1 sec exposures for 5 minutes at a time, then you could schedule the five minute blocks instead of <1 sec blocks.

@michaelbaisch
Copy link
Contributor

I also sometimes run into ValueError('block already occupied') for 30 sec blocks. Just throwing an idea in here: could we just return False in attempt_insert_block() instead of raising the ValueError? This would tell _make_schedule() that this attempt didn't work out and continues to try?

@michaelbaisch michaelbaisch mentioned this issue May 29, 2023
Open
@vitorebconsultores
Copy link

Thank you, I solved some of my issues, although I have been slightly surpsied by some behaviour: -It looks like although a block is made of multiple acquisitions, it cannot be automatically splitted into smaller blocks -it means that telescope can be under utilized if the B session from the R/G/B set is too long for instance, it wont be scheduled at all -Scheduler does not split blocks of smaller priority so that they can be scheduled before and after the optimal airmass slot

Of course, I know that optimal scheduling tend to end-up being NPHard problems, so I won't be too hard on the criticism.

Looks at the nice plots I have been able to generate thanks to your astropy/astroplan/matplotlib:

figure_0 figure_1

No I just need to implement my own constraint for defining my local horizon (in green on the polar grid figure).

Hi, I was wondering if someone can explain how to represent the "green" altitude constraints into the sky_plot? Thank in advance

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
5 participants
@michaelbaisch @bmorris3 @gnthibault @amanda-pagul @vitorebconsultores