Initial scorecard params object

[mollybsmith-noaa]

When a single cell on a scorecard is clicked, the scorecard app will create a JSON object of the parameters that went into that cell, store that JSON object in a mongo collection, and open a new browser window to plot a two-curve timeseries with the stored parameters.

Currently, the most efficient way to store the parameters of a single cell seems to be this:

{
	"appName": "Surface",
	"dateRange": "01/14/2023 19:00 - 02/13/2023 19:00",
	"curve0dataSource": "RAP_OPS",
	"curve1DataSource": "HRRR_OPS",
	"commonCurveParams": 
	{
		"region": "All HRRR Domain",
		"statistic": "RMSE",
		"variable": "2m temperature",
		"threshold": "undefined",
		"scale": "undefined",
		"truth": "METAR",
		"forecast-length": "6",
		"forecast-type": "undefined",
		"valid-time": "undefined",
		"level": "undefined"
	}
}

These are all the fields that will be needed, regardless of app chosen. Fields that are not relevant to a particular app will be given a value of "undefined". For example, the surface app doesn't have a threshold selector, so "threshold" is undefined here.

A temporary mongo collection will be created in matsMethods. js like so:
const ScorecardParamsCollection = new Mongo.Collection("ScorecardParamsCollection");
(There are already three collections created this way: metaDataTableUpdates, LayoutStoreCollection, DownSampleResults.)

The JSON object will be stored in the temporary mongo collection, and its ID will be passed to a new app window to be parsed by FlowRouter.

FlowRouter will pass the ID to a validated method to retrieve the JSON object. Two examples of this functionality can be seen in graphStandAlone.js: matsMethods.getGraphDataByKey.call({resultKey: key,}, function (error, ret) {...} on line 52 and matsMethods.getLayout.call({resultKey: key,}, function (error, ret) {...} on line 81.

Once the parameters are retrieved, these steps should be all that is needed to produce a graph:

1. Set the plotType selector to TimeSeries (most of the apps have that as the default, but not all of them).
2. Create a Curve0 (on the GUI or just in the session?) using the curve0dataSource and the commonCurveParams. Anything not in the commonCurveParams should be set to its default (e.g. Average set to "None").
3. Create a Curve1 (on the GUI or just in the session?) using the curve1dataSource and the commonCurveParams. Anything not in the commonCurveParams should be set to its default (e.g. Average set to "None").
4. Set the date range with the string in dateRange.
5. Execute plotting functions (by clicking "plotMatched" or just calling them directly? Probably plotMatched is easier).

[randytpierce]

This is an excellent plan and write-up. One comment, it probably does not matter but I am not sure you need a validated method to access the temporary mongo collection. We could subscribe to the collection in the client and read the data from mini-mongo on the client side. However, I am also not sure that that would make the whole plan work any better at all because this data is not dynamic i.e. reactive at all. Totally static data. Your idea of the validated method might therefore be best because you have a working example and the data is not reactive. I suppose if there are a lot of scorecards being viewed it might also make sense to not have DDP handling the whole collection at once. So don't change the plan unless something doesn't work. I just wanted to bring up the point. I am surprised and pleased at how concise this seems to be. I'm trying to think about how this helps batch processing. I suppose we can make the plot and then ether present the graph using this technique or do the equivalent of clicking 'preview' and 'save' to save a graph for future reference. In that case the mongo collection would need to not be temporary, I suppose. We may also want some way to capture the id of the plot params document. I suppose we can do what I am doing with the scorecard and migrate a document representing plot params to and from Couchbase. That might also make sense.

[gopa-noaa]

Instead of:
window.open("https://www.esrl.noaa.gov/gsd/mats/" + application + "/" + region + "/" + variable + "/" + statistic + "/" + fcst_len, "_blank");

We could make it more generic, so that it is extensible in future:
window.open("https://www.esrl.noaa.gov/gsd/mats/" + application + "/?URL encoded JSON string");

The JSON for now could be as simple as { "startup": "LoadSettings", "Settings": {settings JSON or db Key to JSON Object} }

Apps on load will check if the URL param JSON is present, and will act on it.
Let me know what you all think...

[gopa-noaa]

Not sure if mongo document IDs are persistent across app instances, probably not, in that case, to have longer lived URLs that can be book marked or shared, we probably can put the whole settings JSON in the URL encoded string, or throw it in Couchbase and use CB doc id.
white_check_mark
eyes
raised_hands

4:50
URL max length is 2048, I think

[mollybsmith-noaa]

After meeting, we've agreed to do an initial prototype with settings stored in mongo, and then switch the functionality to store the settings in couchbase. This will allow different users to share plots with one another, but will require additional engineering.

[ian-noaa]

At the risk of going into the weeds. For the initial data structure you proposed, I think it'd make our lives easier to keep one piece of data per field. E.g. - dateRange should be another JSON object with some sort of start and stop fields that way we can just access each component and don't have to do further string processing in the application.

E.g.

const settings = {
  "appName": "Surface",
  "dateRange": {
    "start": "01/14/2023 19:00",
    "stop": "02/13/2023 19:00"
  },
  "curve0DataSource": "RAP_OPS",
  "curve1DataSource": "HRRR_OPS",
  "commonCurveParams": {
    "region": "All HRRR Domain",
    "statistic": "RMSE",
    "variable": "2m temperature",
    "threshold": "undefined",
    "scale": "undefined",
    "truth": "METAR",
    "forecast-length": "6",
    "forecast-type": "undefined",
    "valid-time": "undefined",
    "level": "undefined"
  }
}

const startDate = settings.dateRange.start
const stopDate = settings.dateRange.stop

[mollybsmith-noaa]

Thanks, Ian! The reason I did not do that is because when you are adding curves into the session, it actually wants *one* date string in the format given here, so doing it this way will require the least amount of manipulation. Is that okay?

…

On Fri, Feb 17, 2023 at 8:46 AM Ian McGinnis ***@***.***> wrote: At the risk of going into the weeds. For the initial data structure you proposed, I think it'd make our lives easier to keep one piece of data per field. E.g. - dateRange should be another JSON object with some sort of start and stop fields that way we can just access each component and don't have to do further string processing in the application. E.g. const settings = { "appName": "Surface", "dateRange": { "start": "01/14/2023 19:00", "stop": "02/13/2023 19:00" }, "curve0DataSource": "RAP_OPS", "curve1DataSource": "HRRR_OPS", "commonCurveParams": { "region": "All HRRR Domain", "statistic": "RMSE", "variable": "2m temperature", "threshold": "undefined", "scale": "undefined", "truth": "METAR", "forecast-length": "6", "forecast-type": "undefined", "valid-time": "undefined", "level": "undefined" }} const startDate = settings.dateRange.startconst stopDate = settings.dateRange.stop — Reply to this email directly, view it on GitHub <#892 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AHBWGZODQ4T4A7MZ6SG7VMDWX6MOTANCNFSM6AAAAAAU4HILUM> . You are receiving this because you authored the thread.Message ID: ***@***.***>

[ian-noaa]

Ah, interesting. That actually makes me wonder if we're doing some unnecessary string manipulation for the dates in some other part of MATS then. If it's already handled elsewhere in the code then it'd make sense to provide it the data as the session is expecting in your original proposal. However, it could be a good opportunity for refactoring if there's a way to simplify/remove code elsewhere in MATS.

[mollybsmith-noaa]

It’s split up in the metadata because daterangepicker requires the start and end dates to be set separately, but we’re kind of bypassing that step here. I’ll keep an eye out for other situations where we might not need the dates to be split, though!

…

On Fri, Feb 17, 2023 at 10:34 AM Ian McGinnis ***@***.***> wrote: Ah, interesting. That actually makes me wonder if we're doing some unnecessary string manipulation for the dates in some other part of MATS then. If it's already handled elsewhere in the code then it'd make sense to provide it the data as the session is expecting in your original proposal. However, it could be a good opportunity for refactoring if there's a way to simplify/remove code elsewhere in MATS. — Reply to this email directly, view it on GitHub <#892 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AHBWGZMQXUMH6QJ53SDHQKDWX6ZBJANCNFSM6AAAAAAU4HILUM> . You are receiving this because you authored the thread.Message ID: ***@***.***>

[mollybsmith-noaa]

If people are interested, the JSON object will now populate with all available fields:

  'click .scTableSigTd': function (e) {
    let myScorecard = Session.get('myScorecard');
    if (myScorecard === undefined) {
      return;
    }
    const row = e.currentTarget.dataset.scorecardrow;
    const rowData = myScorecard['scorecard'].plotParams.curves.find((r) => r['label'] == row);
    const application = rowData['application'];
    // When comparing models, you want forecast minus truth.
    // MATS differences are calculated by Curve1 - Curve0, 
    // so Curve1 is the data-source and Curve0 is the validation-data-source
    const curve0Model = rowData['validation-data-source'];
    const curve1Model = rowData['data-source'];
    const scorecardSettings = {
      "appName": application,
      "dateRange": myScorecard['scorecard'].plotParams.dates,
      "curve0dataSource": curve0Model,
      "curve1DataSource": curve1Model,
      "commonCurveParams": 
      {
        "region": e.currentTarget.dataset.region === undefined ? "undefined" : e.currentTarget.dataset.region,
        "statistic": e.currentTarget.dataset.stat === undefined ? "undefined" : e.currentTarget.dataset.stat,
        "variable": e.currentTarget.dataset.variable === undefined ? "undefined" : e.currentTarget.dataset.variable,
        "threshold": e.currentTarget.dataset.threshold === undefined ? "undefined" : e.currentTarget.dataset.threshold,
        "scale": e.currentTarget.dataset.scale === undefined ? "undefined" : e.currentTarget.dataset.scale,
        "truth": e.currentTarget.dataset.truth === undefined ? "undefined" : e.currentTarget.dataset.truth,
        "forecast-length": e.currentTarget.dataset.fcstlen === undefined ? "undefined" : e.currentTarget.dataset.fcstlen,
        "forecast-type": e.currentTarget.dataset.fcsttype === undefined ? "undefined" : e.currentTarget.dataset.fcsttype,
        "valid-time": e.currentTarget.dataset.validtime === undefined ? "undefined" : e.currentTarget.dataset.validtime,
        "level": e.currentTarget.dataset.level === undefined ? "undefined" : e.currentTarget.dataset.level,
      }
    };
    const baseURL = Meteor.settings.public.home === undefined ? "https://" + document.location.href.split('/')[2] : Meteor.settings.public.home;
    const proxyPerfixPath = Meteor.settings.public.proxy_prefix_path === undefined ? "" : Meteor.settings.public.proxy_prefix_path;
    const appSource = getAppSourceByApplication(application);
    
    // const settingsJSON = JSON.stringify(scorecardSettings);

    if (baseURL.includes("localhost")) {
      e.view.window.open(baseURL, '_blank');
    } else {
      e.view.window.open(baseURL + proxyPerfixPath + appSource, '_blank');
    }
  },

[mollybsmith-noaa]

Parameters are stored and passed to new window:

    const settingsJSON = JSON.stringify(scorecardSettings);
    const hash = require('object-hash');
    const key = hash(settingsJSON);
    matsMethods.saveScorecardSettings.call({
      settingsKey: key,
      scorecardSettings: settingsJSON,
    }, function (error) {
        if (error !== undefined) {
            setError(error);
        }
    });

    if (baseURL.includes("localhost")) {
      e.view.window.open(baseURL + "/scorecardTimeseries/" + key, '_blank');
    } else {
      e.view.window.open(baseURL + "/" + appSource + "/scorecardTimeseries/" + key, '_blank');
    }

[mollybsmith-noaa]

As it happens I think we do need to use couchbase for the scorecards, because each app technically has its own "server" and thus its own mongo collections. I'll use dummy data to finish the plotting routines, but this won't truly work until we use couchbase.

[gopa-noaa]

Ah! yes, didn't think about that, scorecard app stores the JSON, another app needs to pull it, and they are on different servers with different Mongo instances. Yes, dummy code will just be fine, or you can throw it to a file in the score card app, and read from it from the plotting app, in case you want to test it.