Opened 9 years ago

Closed 9 years ago

#262 closed enhancement (fixed)

LIMS3 Queue Setup mods

Reported by: gegorbet Owned by: dzollars
Priority: normal Milestone: future
Component: ultrascan3 Version:
Keywords: review Cc:

Description

The LIMS3 interface needs changes to reflect back-end processing changes and the need to have a front-end-like interface.

for 2DSA, "S-Value Resolution" and "f/f0 Resolution" parameters have "(# of grid points)" changed to "(total grid points)" with defaults of 60.

for both 2DSA and GA, in the Advanced Options section, a -Debug- group box with slider and box to set "Debug Level" (0-4, default 0) and check box to set "Debug Timings" with default being unchecked.

With these new GUI elements, the XML produced and sent along with the job submit would have new tags under <jobParameters>:

  • <debug_level value="0"/> ( 0 to 4 )
  • <debug_timings value="0"/> ( 0 or 1)
  • <s_grid_points value="60"/> (same lower, higher upper limit)
  • <ff0_grid_points value="60"/> (same lower, higher upper limit)

The <s_resolution...> and <ff0_resolution...> tags would remain so new LIMS3 would work with unupdated clusters, but would be given values equal to grid_points/uniform_grid.

Attachments (2)

adv-options.png (19.9 KB) - added by gegorbet 9 years ago.
LIMS Advanced Options: Debug Level object
ff-errconsole.png (46.2 KB) - added by gegorbet 9 years ago.
Firefox error console after entering a Debug Level value

Download all attachments as: .zip

Change History (16)

comment:1 Changed 9 years ago by dzollars

  • Status changed from new to assigned

Some questions:

  • What are the new mins and maxes for S-Value and f/f0 resolution?
  • Would the debug info be saved in the HPC tables along with the other info?

comment:2 follow-up: Changed 9 years ago by dzollars

Another question:

  • In the database table 2DSA_Settings, a value for the S-Value and f/f0 resolution are saved. should these be the new- or the old-style resolution?

comment:3 in reply to: ↑ 2 Changed 9 years ago by demeler

Replying to dzollars:

Another question:

  • In the database table 2DSA_Settings, a value for the S-Value and f/f0 resolution are saved.

for s: -10,000 - + 10,000, with -0.1 - +0.1 excluded. Default: 1-10
for f/f0: 1-15. Default: 1-4

should these be the new- or the old-style resolution?

They should be like the front end.

comment:4 follow-up: Changed 9 years ago by dzollars

I believe I have a first pass at this. Take a look at this instance:

http://uslims3.uthscsa.edu/uslims3_zollarsd

It uses the uslims3_cauma3d database, but I can change that.

comment:5 in reply to: ↑ 4 Changed 9 years ago by gegorbet

Replying to dzollars:

I believe I have a first pass at this. Take a look at this instance:

http://uslims3.uthscsa.edu/uslims3_zollarsd

It uses the uslims3_cauma3d database, but I can change that.

Could you change it to uslims3_cauma3 . I have data there I can test with. I was able to see the parameterization; it looks good to me. I was unable to actually submit a job since I have no data on cauma3d and the dzollars data seemed to have no edits. I'd like to see a job run using the new interface.

comment:6 Changed 9 years ago by gegorbet

I was able to find a data set in uslims3_cauma3d:dzollars that has an edit; and to run a couple of jobs where I varied parameters.

To me, this new LIMS3 functions just as anticipated. I think it could replace all the LIMS3 instances.

comment:7 Changed 9 years ago by dzollars

I do have a couple of runs in there with edits, however, Gary, I would like to see you test it with your own data. So I have changed the database the uslims3_zollarsd instance uses to match what is in cauma3. As I don't have much data in that one I can't see too much, but it looks like it is working.

Let me know how it works and I'll commit it to all instances.

comment:8 follow-up: Changed 9 years ago by gegorbet

The newest uslims3_zollarsd on cauma3 has some problems.

  • The defaults for s and f/f0 maxima are now 100,100 (should be 10,4).
  • S-value and f/f0 parameter names have an inconsistent mixture of lower and upper case.
  • The debug_timings check box is apparently ignored - always "1" regardless of check.
  • The debug_level slider does not function correctly - cannot move it from left to right.
  • Band Loading Volume parameter is unclear - default is non-zero but there is no Band Forming check box - if Volume parameter does double duty (Vol=0 ->BForm=false; Vol>0 -> BForm=true), then the default for Volume should be 0.

comment:9 in reply to: ↑ 8 Changed 9 years ago by dzollars

  • Keywords review added

Notes:

  • The defaults for s and f/f0 maxima are now 100,100 (should be 10,4).
  • S-value and f/f0 parameter names have an inconsistent mixture of lower and upper case.
  • The debug_timings check box is apparently ignored - always "1" regardless of check.

All fixed.

  • The debug_level slider does not function correctly - cannot move it from left to right.

Works for me.

  • Band Loading Volume parameter is unclear - default is non-zero but there is no Band Forming check box - if Volume parameter does double duty (Vol=0 ->BForm=false; Vol>0 -> BForm=true), then the default for Volume should be 0.

Actually what happens is that LIMS checks the database to discover what characteristics the centerpiece has. If it's not a band-forming centerpiece it overrides whatever you put in there and replaces it with 0.

Added checks for |s-min|, |s-max| > 10000

All instances updated.

Changed 9 years ago by gegorbet

LIMS Advanced Options: Debug Level object

comment:10 follow-up: Changed 9 years ago by gegorbet

For the most part, this new LIMS works beautifully for me. There is a problem with Advanced Options : Debug Level as shown in the attached file (for certain browsers). It works fine in Safari and Firefox on my Mac; acts strangely, as shown, in Firefox on my Ubuntu main development machine. There certainly could be a bug in this Firefox or its JavaScript, although it acts normally on most web sites. Could you have one more look at the code, Dan, around the Debug Level object, to see if anything might explain what is shown in the attached file.

comment:11 in reply to: ↑ 10 Changed 9 years ago by dzollars

For the most part, this new LIMS works beautifully for me.

Great.

There is a problem with Advanced Options : Debug Level as shown in the attached file (for certain browsers).

I have seen this behavior before. I associate it with the browser not playing well with the JavaScript?. However, it is not a problem in the common functions, as other sliders appear to be working in the very same image. Also, the ones that are not working are the new ones.

Since the problem you are having is in Firefox, I suggest a couple of ideas. First, try refreshing the page with the shift key pressed. This forces the JavaScript? to be re-read. Also, sometimes it is necessary to restart Firefox. Finally, try this: in options, open the error console and clear it out. Then, with the error console where you can see it, refresh the lims page. This will tell you if it can't find the JavaScript? function, or any other JavaScript? error that it comes across. If you get an error there and can't solve the issue with these ideas, let me know what the error says. Hopefully there will be a line number or something.

Changed 9 years ago by gegorbet

Firefox error console after entering a Debug Level value

comment:12 follow-up: Changed 9 years ago by gegorbet

The appearance of Debug Level is back to what it should be, but the slider still misbehaves. The slider knob cannot be moved left-to-right. If I click to the far right, the knob moves there and I can then move it right-to-left. But I can never move it left-to-right.

If I enter into the value box, I get a message in the error console window as shown in the most recently attached image.

I noticed in the page source that the "id" value for debug_level includes "slider_input" where all the other (working) sliders have "slider-input" (dash versus underscore). Could that make a difference?

comment:13 in reply to: ↑ 12 Changed 9 years ago by dzollars

The appearance of Debug Level is back to what it should be, but the slider still misbehaves. The slider knob cannot be moved left-to-right. If I click to the far right, the knob moves there and I can then move it right-to-left. But I can never move it left-to-right.

If I enter into the value box, I get a message in the error console window as shown in the most recently attached image.

This is getting very odd. That message is basically telling you that the browser is not understanding the JavaScript. The code looks identical to the others, except that I took out the display of minimum and maximum. Just now I put that back in at http://uslims3.uthscsa.edu/uslims3_zollarsd so you can see if that makes a difference. JavaScript is generally very finicky, and sometimes the only way is to put in some debug statements and see where it is going awry.

I noticed in the page source that the "id" value for debug_level includes "slider_input" where all the other (working) sliders have "slider-input" (dash versus underscore). Could that make a difference?

I just now double checked the code, and they do line up correctly. Those values have to match in the php and the JavaScript, and if they don't it won't work on anybody's browser.

I'm still not convinced that your browser is working correctly. It appears to work on every browser I've tested.

comment:14 Changed 9 years ago by dzollars

  • Resolution set to fixed
  • Status changed from assigned to closed
Note: See TracTickets for help on using tickets.