Contributors:

Algie Morgan

Dan Cary

Summary

This document highlights changes to the JOIDES Resolution laboratory data management environment during Expedition 396T.

The activity log for this expedition will be placed here: https://banff.iodp.tamu.edu:8443/display/HIS/JR+activity

Special Projects

During expedition 396T, the developers worked on the following projects:

• LabVIEW upgrade: upgraded all instrument hosts and development computers from LabVIEW 2019 to LabVIEW 2021

• IMS upgrade: upgraded all instrument tracks from IMS 11.3 to IMS 12.0¹

• Tomcat web server upgrade:  upgraded all Tomcat servers from Apache Tomcat 9 to SUSE curated Tomcat 9; shipboard LIMS services web infrastructure now corresponds to shore infrastructure.

• SVN: new labsystems repository created on ship SVN host (http://build.ship.iodp.tamu.edu/svn).

• IRIS: wrote two web services to retrieve data from IRIS system and store the data in LORE.  This in support of the IRIS system being developed by TAS and Ops teams to replace aging RigWatch system.

• Auther: revising Auther to:

  • Port it to IODP standard Angular version.

  • Implement new security features mandated by TAMU.

  • Implement IODP themed appearance.

  • Add capability to create application-specific environment.

  • Additional bug-fixes and enhancements.

¹The SRM host was still running IMS 10 at the start of the 396T transit / tie-up; this was also upgraded to 12.0.

General Duties Performed

• Routine expedition support.

• Maintenance to software applications (detailed below).

• Assisted with data management in cases where LIME and other tools were not sufficient.

• Other duties as assigned.

Software Changes:

Other Changes

• No other changes made on this transit / tie-up.

Outstanding Issues

(remaining from Expedition 396)

• Catwalk: There are some outstanding Catwalk issues that may come up again:

  1. Sometimes when Catwalk is terminated (esp. if terminated abnormally, e.g. a crash), one or more of its actors might stay running in the background.  When Catwalk is launched again, that orphaned actor can resume it's function, seeing and responding to events from the new instance.  This seems rare, but it occurred at least twice on this expedition.  The errant actor seems to always be DataManagerActor, but in testing LogGatherer also had this issue (though with less noticeable results).  When this occurs, Catwalk becomes sluggish and behaves strangely, because two copies of DataManager and responding to requests for data.  Catwalk users do not generally have the skillset needed to search out and manually (via Task Manager) kill the errant process and developers might not find out immediately about the issue.  Generally, if you hear that Catwalk is becoming "slow" and/or samples from previous activity are inexplicably re-appearing in its table, this is probably the cause.
     
     A solution to this problem is being developed, but not complete.  In the future, each instance of an LDAQ application will have a randomized "key" that it will give to each controller and actor that it launches – and that will be included in every event data payload.  If an actor sees an event that does not include the key it expects, it will ignore that event.  Additionally, a special event, called "LDAQ_ROLL_CALL" will be exempt from this rule.  When any module sees this event, it will respond with its own name and key value.  This way, LDAQ applications can actively monitor themselves and kill off any modules that respond to the roll call with the wrong key.
     
     
     

  2. A minor issue: when Catwalk is partially obscured behind other windows, if the user clicks on the area occupied by the LabelPrinterActor's UI panel, Catwalk will not come to the front.  This is because LabelPrinterActor is an EXE-type module, so its panel in Catwalk is actually an application's main window, from the OS's perspective.  
     
     A solution to this problem would be to have LabelPrinterActor fire an event when it comes to the front, so that the controller above it can respond by bringing the main Catwalk window to the front.  From the user's perspective, this would have the desired effect – Catwalk would come to the front.  This should not be too difficult, but has not yet been done.
     
     
     

  3. Catwalk currently has an issue that is both a bug and a feature, depending on the circumstance.  This issue is getting a lot of visibility currently, but a proper resolution that will satisfy everyone is not yet complete.

     • In Catwalk, volume is auto-calculated for certain sample types based on the length and core type. 

     • A feature was implemented during development of the application such that when the user changes the sample type (e.g. of a new sample, before uploading), the volume should be blanked out if the new type is not one for which volume is calculated.   This is important because if the user (e.g. accidentally) first selects a sample type for which volume is calculated, then corrects the sample type to one for which volume is not calculated, the user might not notice that the (now erroneous) volume was calculated for the old sample type if it is not blanked out when the sample type is changed.

     • The problem is that when a template sample is "dropped" onto a section to create a new catwalk sample, the software sees that action as a "change" to the values in the sample table.  This causes all the auto-fill and auto-calculate formulas to run (a desirable feature). If the sample being created is one for which volume is not calculated, the volume will be blanked out, even if a volume is specified in the template.

     • Request number, which is auto-filled when the user selects a request code, has this identical issue.

     • The workaround to this is simply to alter the formulas to perform the action desired by the current curators and techs – either to blank out the volume and/or request type, or not.

     • A solution to this has been envisioned, but not completed: Catwalk needs to be "aware" down at the level where it is responding to cell value changes, whether a change was triggered by explicit user action on that cell, or as part of a template sample being filled out.  Values originating from a template sample should not be altered by auto-fill formulas.
       
       
       

• MUT: There is a new Kappabridge device on the ship, but not yet in use, that may create files different from what MUT expects.  Examples of these files did not become available in time for changes to be made to support them.
  
  
  

• Velocity Gantry: If non-cored samples are run through the software, the files generated by IMS will have "XXXX" in place of the text ID, both in the filenames it generates, and within the main run file.  To workaround this problem, the following procedure was implemented:

  1. Technicians entered the sample's text ID in the comment.

  2. A Powershell script was written that would find the text ID in the comment (within the main run file) and rename all associated files and update the run file with the proper text ID.  Once that is done, the files can be uploaded by MUT.  For reference, this script is stored under the TAS folder at TAS\AD\people\blaisdell\processfiles.ps1.
     
     
     

• Label printers in general: Apparently many of the Zebra printers are new and there seems to be an issue where things are not always aligned exactly as they were on the older printers.  Several times during this expedition, the MCS and developer needed to tweak the settings on the printers so that bits of the information was not cut off on right or left.  In some cases this was not entirely possible, and all that could really be guaranteed was that the barcode itself would be scannable.  It seems that on some of the smaller labels, the information we are trying to print on them is slightly wider than the label itself.  It is unclear what we can do about this.  The printers may have features which can resolve these issues.
  
  
  

• Tomcat servers and power outages: During this expedition, the server room in the MCS office suffered two complete power outages.  The MCS group has been working to solidify a procedure for bringing everything back online after such a failure, and recovery from the second occurrence was much faster than the first, but the following information is important for developers to be aware of:

  1. It is almost certain that the Tomcat servers will come back online before Oracle does, and therefore the Tomcat servers will have to be restarted after Oracle is back up.  MCS personnel are not typically as aware of the state of the Tomcat servers as the developers are.

  2. Confluence runs on a server called "teton", and runs under Tomcat on that machine.  Therefore, there are five Tomcat servers that may need attention after such an event. (in addition to matterhorn, elcapitan, olympus and uluru).