NRAO Home  >  Green Bank  |  Wiki Topic:    GB > Dynamic > DanaWeatherText (r1.1 vs. r1.4)
   Changes | Index | Search | Go
 <<O>>  Difference Topic DanaWeatherText (r1.4 - 01 Aug 2008 - DanaBalser)
Changed:
<
<

  1. How should grade B hours be incorporated into the PF? In many cases the grade B hours come from excess time at the Galactic Center. Or they could include a lot of time that we might not expect will ever get scheduled but it is good to have around in the queue. So I would recommend that we not include grade B hours in the PF calculation.
  2. How should semester boundaries be incorporated into the PF?
>
>

  1. How should grade B hours be incorporated into the PF? In many cases the grade B hours come from excess time at the Galactic Center. Or they could include a lot of time that we might not expect will ever get scheduled but it is good to have around in the queue. So I would recommend that we not include grade B hours in the PF calculation. (For trimester 08C and/or in the future, we may change the meaning of A and B graded proposals where the majority of proposals that we "plan" to schedule in the upcoming trimester are rated B---that is, we change the distribution of A and B. So we need to include B rated proposals. Currently, the grade is associated with the project and not the session. Furthermore, for projects that have both A and B hours the grade is specified as A until the A hours have elapsed and then the grade is specified as B. But this is not how we really want the DSS to work since we may want the B rated hours to be scheduled before th A rated hours. Therefore for 08B I argue we should include both A and B hours in the PF. We should probably rethink this for the alpha version.)
  2. How should trimester boundaries be incorporated into the PF?

 <<O>>  Difference Topic DanaWeatherText (r1.3 - 16 Jun 2008 - DanaBalser)
Changed:
<
<

  1. Total allotted hours versus total project hours? It is possible that the sum of the total allotted hours over all sessions for a particular project is larger than the total project hours. For example, a project may have a total of 100 project hours and be composed of 6 session with 20 allotted hours each. Of course once the
project uses 100 hours the project is done. So what do we use to calculate PF?
>
>

  1. Total allotted hours versus total project hours? It is possible that the sum of the total allotted hours over all sessions for a particular project is larger than the total project hours. For example, a project may have a total of 100 project hours and be composed of 6 session with 20 allotted hours each. Of course once the project uses 100 hours the project is done. So what do we use to calculate PF? I would argue that we just use the total allotted hours. Mostly because it is easier and I don't think this will occur very often to make much of a difference. I assume this is really a question of do we sum the session hours or the project hours. We can try summing the session hours for this test and then see how it goes. we can monitor things at the end of the tests to see how many projects had significant;y more session hours than project hours (or even could do this now) to see if that makes sense. Good, also I assume we need to not include maintenance in pressure computations.
  2. How should grade B hours be incorporated into the PF? In many cases the grade B hours come from excess time at the Galactic Center. Or they could include a lot of time that we might not expect will ever get scheduled but it is good to have around in the queue. So I would recommend that we not include grade B hours in the PF calculation.
  3. How should semester boundaries be incorporated into the PF?
Deleted:
<
<

I would argue that we just use the total allotted hours. Mostly because it is easier and I don't think this will occur very often to make much of a difference.

I assume this is really a question of do we sum the session hours or the project hours. We can try summing the session hours for this test and then see how it goes. we can monitor things at the end of the tests to see how many projects had significant;y more session hours than project hours (or even could do this now) to see if that makes sense. Good, also I assume we need to not include maintenance in pressure computations.


 <<O>>  Difference Topic DanaWeatherText (r1.2 - 24 May 2008 - MarkClark)
Changed:
<
<

Dana's email, comments in blue from Karen

>
>

Dana's email, comments in blue from Karen, green from Mark

Added:
>
>

Whew!

Changed:
<
<

>
>

Good, also I assume we need to not include maintenance in pressure computations.


 <<O>>  Difference Topic DanaWeatherText (r1.1 - 22 May 2008 - KarenONeil)
Added:
>
>

%META:TOPICINFO{author="KarenONeil" date="1211451117" format="1.0" version="1.1"}% %META:TOPICPARENT{name="MeetingMinutes22May08"}%

Dana's email, comments in blue from Karen

Put on the wiki in case we don't get through this by 10:30.

Minimum Observing Conditions:

After we produce a 24 hour schedule one day into the future we check the current weather conditions (~30-60 minutes before a session starts) to see if the minimum observing conditions are met (current observing efficiency > minimum observing efficiency - 0.1 and that the tracking limit is still 1.0). If these minimum observing conditions are not met then we try to run a backup session.

The question is how to handle fixed and windowed sessions vis-a-vis the minimum observing conditions?

Here is my opinion:

Fixed: we have to run these sessions even if the conditions are poor. I think we have to do this

Windowed: apply the minimum observing conditions except for the last observing opportunity (this could be the last 24 hours) and then treat the session as fixed. This could work for now but is not a good long term solution, as we need some sort of look ahead

Schedule Boundaries:

Currently the packing algorithm schedules the telescope for 24 hours. How should we deal with the boundary? There are several options:

  1. Force the schedule to end at 24 hours exactly. This means that even if the best score spans the 24 hour boundary (e.g., 22 -> 2 hr), even if the best score spans the 24 hour boundary (e.g., 22 -> 2 hr), we would find a lower ranked session to fit (e.g., 22-24 hr).
  2. Leave a whole in the schedule before the 24 hours (e.g., onlyschedule from 0-22 hr).
  3. Schedule beyond the 24 hours (e.g., 0-24 hr plus 24->2 hr).

I would argue for number 3. I see no reason why we have to have a hard limit at 24 hr. One advantage of number 2 is that we do not have to use a weather forecast that is beyond 48 hr into the future and therefore will have a better forecast. One disadvantage of number 2 is that we may have a significant gap in our "24 hr" schedule. For example, if the session that fits in the end spans 18->2 hr we will only be producing a schedule that is 0-18 hr. The forecast from 48-60 hr should not be much worse than the 36-48 hr forecast so number 3 seems like the better choice to me. We should be able to simulate what the differences are in terms of observing efficiency and how the number of backups are effected by these different choices.

It appears that the packing algorithm does the following (from Mark):

"It turns out we do not have a choice about keeping or rejecting telescope periods which straddle the end of the packing boundary. Unless we want to have to schedule with 24-hour overlaps, any telescope period that straddles a packing boundary must be kept. For example, we schedule from noon to day to noon tomorrow. Pack schedules sessions from noon today through midnight tomorrow labeling the telescope periods A through Z with A starting at noon today, Z ending at midnight tomorrow, and M straddling noon tomorrow. Pack will return telescope periods A-M, i.e. it will schedule a little pass the requested noon tomorrow. Another way of stating it, is pack will return all telescope periods that start within the range given it."

Three seems like the best choice to me, also

Pressure Factor (PF):

One term in the ranking equation is the pressure factor. We have an LST pressure factor and a frequency band pressure factor. Recall that the PF is:

PF = 1 + ln(n/d)

with

n = d + r

where d is he number of completed (done) hours and r is the number of remaining hours for each LST hour or frequency band.

There are several questions about the PF:

  1. When do we reset the PF? That is, when do we set d = 0? In the simulations that Jim and I ran we reset the PF at the start of the first trimester and let it run the entire year. I don't have a strong opinion about this but I guess I would reset the PF at the start of each trimester. But do seasonal variations matter? For the summer test they don't. After that we should simulate both ways and see, but I would think trimester boundaries would be a sensible time to reset everything.
  2. How do we treat backlog sessions? During any trimester there will be sessions in the backlog that are partially completed. Do we count the hours completed in the PF? It may not matter very much but I guess I would not count the hours completed for backlog sessions since these hours certainly will not compete for the current trimester. This seems tied directly to (1). If we reset every trimester then we should also not pay attention to previously used hours at the start of a trimester
  3. Total allotted hours versus total project hours? It is possible that the sum of the total allotted hours over all sessions for a particular project is larger than the total project hours. For example, a project may have a total of 100 project hours and be composed of 6 session with 20 allotted hours each. Of course once the
project uses 100 hours the project is done. So what do we use to calculate PF?

I would argue that we just use the total allotted hours. Mostly because it is easier and I don't think this will occur very often to make much of a difference.

I assume this is really a question of do we sum the session hours or the project hours. We can try summing the session hours for this test and then see how it goes. we can monitor things at the end of the tests to see how many projects had significant;y more session hours than project hours (or even could do this now) to see if that makes sense.


Topic DanaWeatherText . { View | Diffs | r1.4 | > | r1.3 | > | r1.2 | More }
Revision r1.1 - 22 May 2008 - 10:11 GMT - KarenONeil
Revision r1.4 - 01 Aug 2008 - 21:08 GMT - DanaBalser
Content copyright © 1999-2007 by the contributing authors.
All material on this collaboration platform is the property of the contributing authors.