Subject: Re: [infrastructure 14141] Re: [sloan-25mlog 2925] 2.5m obslog From: Nathan De Lee Date: Fri, 15 Apr 2016 11:18:34 -0400 --------------090005070007040301090807 Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 8bit Hi Kaike and Jose, The keyword is stored in the plate design file (keyword apogee_exposure_time). This is where everything should be getting that information. Given that this doesn't seem to be easily reproduced, I suspect it is a bug of some sort and not two different sources of exposure information. Nathan José Sánchez-Gallego wrote: > Actually I tried to reproduce this for almost an hour a few days ago > and I was completely unable to do so. I thought that maybe Brian > making the new SOP version current could have solved the problem (as > it treats co-observing plates in carts 7, 8, 9 as APOGEE-only). It > seems that is not the case. > > I don’t think this is a keyword problem, or at least not something > simple. If it were so, the problem would be reliably reproducible. As > far as I know the only place in which the exposure time information is > stored is in plateDB, and it’s only read by platedbActor and stored in > a keyword there. That keyword is read by sopActor which populates the > exposure times to use for both MaNGA and APOGEE. > > Have you noticed any pattern in when this happens? I see that cart 7 > was the first of the night. Was some other cart loaded before it? I’ll > try to find some time today or this weekend to have a look at the > problem. If you encounter the problem again, can you please record all > the possible information (order of plates observed, commands issued, > STUI buttons clicked) and either put it in the log or in the ticket? > Until we can reliably reproduced the problem it’s quite difficult to > find a fix for it. > > Cheers, > > José > > On April 15, 2016 at 07:46:09, Kaike Pan (kpan@apo.nmsu.edu > ) wrote: > >> Hi Jose, Brian, Nathan, >> >> We are having this issue quite often. I am wondering where SOP gets >> the information: >> whether a plate is “DAB”, where APOGEE wepapp gets the information. >> If they get >> the information from different sources, we may have synchronizing >> problem. If they gets >> the information from the same source, from example, both from >> plateDB, either SOP >> or webapp has issue to read correct information. Could this be a >> library key word issue? >> If you can investigate this when you have time, it will be much >> appreciated! thanks, >> >> -kaike >> >> >> > Notes >> > ===== >> > (1) SOP defaulted to 1000s exposures on cart. 7, 8911, despite >> 'DAB' set as 'F' >> > (see Ticket #2373). Since a 94-read exposure had already begun (and >> we had ample >> > time before the next plate was available), we completed the DAB >> pair and then >> > switched to 500s (47-read) exposures for the remainder of the plate. >> >> >> >> ____________________________________________________________ >> Common APO Hardware and Software >> https://trac.sdss.org/tracmailman/browser/private/infrastructure/index.html --------------090005070007040301090807 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit Hi Kaike and Jose, The keyword is stored in the plate design file (keyword apogee_exposure_time). This is where everything should be getting that information. Given that this doesn't seem to be easily reproduced, I suspect it is a bug of some sort and not two different sources of exposure information. Nathan   José Sánchez-Gallego wrote: body{font-family:Helvetica,Arial;font-size:13px} Actually I tried to reproduce this for almost an hour a few days ago and I was completely unable to do so. I thought that maybe Brian making the new SOP version current could have solved the problem (as it treats co-observing plates in carts 7, 8, 9 as APOGEE-only). It seems that is not the case. I don’t think this is a keyword problem, or at least not something simple. If it were so, the problem would be reliably reproducible. As far as I know the only place in which the exposure time information is stored is in plateDB, and it’s only read by platedbActor and stored in a keyword there. That keyword is read by sopActor which populates the exposure times to use for both MaNGA and APOGEE. Have you noticed any pattern in when this happens? I see that cart 7 was the first of the night. Was some other cart loaded before it? I’ll try to find some time today or this weekend to have a look at the problem. If you encounter the problem again, can you please record all the possible information (order of plates observed, commands issued, STUI buttons clicked) and either put it in the log or in the ticket? Until we can reliably reproduced the problem it’s quite difficult to find a fix for it. Cheers, José On April 15, 2016 at 07:46:09, Kaike Pan (kpan@apo.nmsu.edu) wrote: Hi Jose, Brian, Nathan, We are having this issue quite often. I am wondering where SOP gets the information: whether a plate is “DAB”, where APOGEE wepapp gets the information. If they get the information from different sources, we may have synchronizing problem. If they gets the information from the same source, from example, both from plateDB, either SOP or webapp has issue to read correct information. Could this be a library key word issue? If you can investigate this when you have time, it will be much appreciated! thanks, -kaike > Notes > ===== > (1) SOP defaulted to 1000s exposures on cart. 7, 8911, despite 'DAB' set as 'F' > (see Ticket #2373). Since a 94-read exposure had already begun (and we had ample > time before the next plate was available), we completed the DAB pair and then > switched to 500s (47-read) exposures for the remainder of the plate. ____________________________________________________________ Common APO Hardware and Software https://trac.sdss.org/tracmailman/browser/private/infrastructure/index.html --------------090005070007040301090807--