Create new log datasets manually

[patzinak]

Instead of automatic creation of the datasets every week/10 days it would be great to allow user manually start the new log files. The new set of files should be distinguished by the cooldown name that the user should provide (and a date_time string should be appended to the name automatically).

[nmGit]

This should be no problem. Will do.

[nmGit]

@patzinak @amopremcak I finished adding the ability to save/rename datasets. There were a few things; however, that I left out.

1. Due to the way the datachest works, you cannot save datasets outside of the DATA_CHEST_ROOT directory. I do not know if this is something Alex can/wants to change about dataChest. A way to get around this limitation would be to define DATA_CHEST_ROOT at a very high level directory (i.e. C:\Users\Noah). The problem with doing this is that by default, MView will create/look for a previous dataset upon opening. These default datasets are located relative to DATA_CHEST_ROOT so there is potential for a folder/file to be created where it shouldn't be.

2. I did not automatically add the date_time string to the end of the data set name (but you can give a dataset any name you want). Here is why: if I name a data set 'Random', datachest will create a data set called 'bch2003fip_Random.hdf5'. Technically the 'bch2003fip' piece contains information about date and time which afaik cannot be disabled(Alex?). Also, Alex, why prepend a cryptic data/time descriptor to the name? I feel like ideally it should just be a raw date and time so that it is human-readable. It should also be appended to the end of the data set name, not the beginning so that when browsing for a dataset we can sort data sets alphabetically by name. Can there be an option to disable appending date/time info completely?

I will continue working on thing 1, but I think Alex might need to look at thing 2.

[nmGit]

Oh, and also to disable data logging by default you can add the 'log = False' keyword argument to the MDevice.addParameter() method. e.g.

LeidenDRTemperature.addParameter("Pressure","pressure", None, log = False)

[patzinak]

1. Not sure that I totally understand the problem but it was precisely the Alex's idea to make it hard to store data beyond DATA_CHEST_ROOT. If the computer is connected to the network, it should be pointed to the smb folder that contains the data.

2. Starting with the name is better for sure. I have also a very slight preference to a human readable date_time format but I'm okay with what we currently have. Btw, @nmGit , is the fact the plot labels do not have whitespaces related to the way you save the data? Could you just replace whitespaces with underscores when you save the data and replace them back when you make the labels? If not this should be a separate issue.

[amopremcak]

Why are you trying to save anything outside of the directory in which all data collected in this lab should be stored @nmGit?. Where would this location be and why does it differ from where everything else would be stored? Are you trying to toggle between local and smb?

The dateStamp that is appended to the front of all dataset names is really there for uniqueness. Since people often acquire data and use the same dataset name for multiple sets within a given folder, you must do something to make this name unique. Whether you append something to the end or beginning of a dataset name is a matter of preference but the point is too preserve the chronological ordering of files within a folder using dateStamps.

[nmGit]

@amopremcak I was thinking that people might want to save data like on a usb drive or something. Also that if I allow people to save data wherever they want, then what is the point if they are limited to only folders in DATA_CHEST_ROOT?

One of the problems I see with using locations relative to DATA_CHEST_ROOT is that if there are two different data collection operations running on the same system, then they have no choice but to store data in the same directory (DATA_CHEST_ROOT) which is not good.

The datachest library in general is a very useful and well thought out tool, but nothing is without a few complaints. Coming from someone who uses it everyday, a huge caveat that I have with it is that users are limited to storing data relative to one directory as opposed to being given free reign of their entire file system. I see what your intent was with having a root directory and storing data relative to it, but I'm finding that it is more of a roadblock than a feature.

Maybe a solution would be to say that if DATA_CHEST_ROOT is defined as an environment variable, then data chest should behave as it does now. However, if DATA_CHEST_ROOT is not defined, then there is no limit placed on where the user can store their data.

Also, a human-readable date stamp will also always be unique and I really do think it should be appended, not prepended to the dataset name.

[amopremcak]

I appreciate the feedback @nmGit. I can make a change so that a user can supply their own root directory. I will implement it in such a way that if a user supplies their own root path, it will ignore the environment variable entirely.

As for the dateStamp, I'd like to talk with @patzinak and @roboguy222 about there thoughts on the matter. I don't really have a preference. The dateStamp is actually just a shorter way of encoding the date/time that doesn't disclose the age of a project.

[patzinak]

What is the status here @nmGit Seems like you have implemented the original suggestion. If there is something you or Alex want to work on, could you please rename this issue or close it.