ASIAA ALMA Taiwan ALMA
Home \ Call for Proposals \ ALMA Feedback

ALMA Feedback:

Thank you for sending us your valuable feedbacks. We are glad that you find the user workshops, proposal writing camps, web interface, and documentation useful for writing your ALMA proposals. In the following, we list our answers/responses to your major concerns and problems:

A: Proposal preparation and submission with OT

  1. confusion of time splitting between two ALMA agents (EA and NA)

    RESPONSE: This split option is mainly to get time for a big project.

    Since there is only one TAC, there will be only one overall ranking. Each region will extract from the overall ranking the ranking list for its own proposals. Thus, getting top priority in two regions should be the same as getting the top priority in the more competitive region that with higher over-subscription rate and/or more stronger proposals.

    To facilitate the explanation, here we assume someone submits a proposal with this split option, and requests a total time of 10 hrs, i.e., 5 hrs in EA and 5 hrs in NA.

    If one selects the split option, it depends on where the proposal stands in BOTH queues. For the proposal to be accepted, it needs to fit within BOTH queues; i.e., for the above proposal submitted for Cycle 1, the 5 hrs needs to fit within the NA 270 hr allotment and the other 5 hrs needs to fit within the EA 180 hr allotment. If it only fits within one queue and not the other, it will not be given a "High Priority" status.

    Note that this is not necessarily a double jeopardy; it depends on the relative over-subscription between the two regions, and how close to the dividing line the proposal lies. Not obvious for the example of a 10 hrs proposal; more-so for larger proposals where e.g. fitting 20 hrs into two queues is easier than fitting 40hrs into one.

    On the other hand, a Taiwanese PI can submit two 5hr proposals SEPARATELY, one with EA as the Executive, another with NA as the Executive. Then each part would be judged against the relevant queue, - they get all the time if they pass both Executives cutoff; they get 5 hrs if they only pass one Executives cutoff.

    Note that this workflow would only work for projects that could be split by number of targets, not total integration time, since there is a prohibition against submitting the exact same proposal with different Executive affiliations.

    For more explanation, please see here.

  2. Lack of connection between CASA simulated results and OT input parameters.

    RESPONSE: CASA simulation and OT are currently independent ALMA utilities. Therefore, they were introduced and demonstrated separately. New users indeed could get lost and would not know how to connect the two. In the next workshop, we will prepare a guide illustrating the connection between the two.

  3. Request of spectral scan mode.

    RESPONSE: The spectral scan mode is in the plan for cycle 2

  4. Relax the restrictions on the number of targets, pointing, tuning, etc in Cycle 2.

    RESPONSE: These items are still under discussion.

  5. incorrect overhead estimate

    RESPONSE: We apologized for the incorrect overhead estimate. Here is the link to the answer for that issue: here.

    "The 4th octile of PWV is being used for all calibration time estimates in the Cycle 1 version of the OT rather than the octiles assumed for the source as given in Figure 8.1 and Table 8.2 of the Technical Handbook. This is leading to very large estimated calibration times, particularly at Band 9 and parts of Band 7 (the effect at Bands 3 & 6 should be quite small). Since users specify science goals in terms of a requested RMS rather than a time, they should DO NOTHING about this in their proposal. After the Cycle 1 proposal deadline but before proposal assessment, an updated version of the OT correcting this error will be used to recalculate the time estimates based on the proper PWV octiles. The revised times will be used for the proposal review. Users will be able to download the updated OT and retrieve their submitted Cycle 1 proposals from the archive to see these revised time estimates."

B: Problem report and Helpdesk

  1. slow response by (NA) helpdesk

    RESPONSE: Our plan is to take care of Taiwan users (both under EA and NA), including helpdesk ticket. We can handle the EA helpdesk tickets. However, we still can not take care the NA helpdesk tickets submitted from Taiwan, because NA helpdesk is still not be able to forward those tickets to us due to technical issues. For the time beings, NA staff will take care of those tickets. Thus, please let us know next time when you have not received your answer within 2 days. We can send a reminder to NA helpdesk.

C: Observation and data delivery

  1. slow data delivery

    RESPONSE: This delay was due to partly the administrative latency (from observation to QA2 and from QA2 to delivery), partly the lack of man power (JAO does not have enough man power and thus turn to ARC), and partly due to the unexpected technical issues in the data reduction process in the early phase of the operation. Now we have reduced some of the administrative latency. Also, we have more experience now and should be able to reduce the time for the QA2 process. However, we still need more man power. Please let us know if you are interested in helping this QA2.

  2. no raw data in the data delivery

    RESPONSE: It is the current JAO's policy not to include the raw data. The data which are delivered are the ones where Tsys, wvr and the antenna positions are already applied. These data still include all calibrators but only the science spw. The bandpass, gain, ... calibrations can still be done again with these data.

D: Data reduction and CASA

  1. Converting from CASA format to MIRIAD format (passing through FITS) causes the velocity labeling to become messed up.

    RESPONSE: Unfortunately, CASA does not support the conversion to MIRIAD format yet. As far as we know, no one is working on that function. Thus, we don't expect the FITS header will contain enough information for MIRIAD now.

  2. No Position-Velocity diagram tool

    RESPONSE: PV diagram tool is already in the wish list of CASA development plan. Some simple PV diagrams can be easily produced, one has just to select the correct axis in the configuration panel.

  3. A workaround to produce PV diagrams for different posistion angles is the following (CASA example):
    ### make Position-Velocity maps
    ### rotate 3Dcube
    ia.open('TWHydra_HCOplusline.image')
    ia.rotate(pa='-40deg', outfile='TWHydra_HCOplusline.image.rotm40')
    ia.done()
    ### select regions and velocity ranges
    mybox = rg.box(blc=[33,33,0,44], trc=[67,67,0,70])
    ia.open('TWHydra_HCOplusline.image.rotm40')
    ia.rebin(region=mybox, outfile='slice.image', bin=[33,1,1,1], dropdeg=True)
    ia.done()
    ### check the image with viewer
    imview('slice.image')

  4. some tasks in CASA are too interactive or lacking some defaults, which makes inspecting the data cumbersome and confusing.

  5. Visibility data point display is sometimes very hard to see

  6. Displaying channels maps in CASA is a bit awkward, the task imview gives one plane at a time, which is not always useful. Adjusting the display preferences and increasing the number of panels causes each panel to become awfully small and have a huge space between panels.

  7. RESPONSE: We will send these above comments to the CASA developer. Please also check the following CASA wish list and feel free to contribute: whish list

Last updated on Nov 13, 2012

Valid XHTML 1.0 Transitional Valid CSS!