Closed aremazeilles closed 3 years ago
yaml information updated and uploaded
I just uploaded the image to DockerHub
There is a subject_S_choice_metabolicCost.yaml for one of the entry points. I assume this file keeps constant for all the conditions/runs of the experiment for a subject. Could the information inside be included in subject_S_info.yaml? If not I should change the PiManager logic to handle this. This would have sense if this kind of file is used by other algorithms (and I think it is not the case).
The example I have is as follows:
$ ls
condition_01.yaml
subject_01_cond_01_choice_metabolicCost.yaml
subject_01_cond_01_run_01_balance.csv
subject_01_cond_01_run_01_chrono.csv
subject_01_cond_01_run_01_hrv.csv
subject_01_cond_01_run_01_jointAngles.csv
subject_01_cond_01_run_03_questionnaire_borgScale10.csv
subject_01_cond_01_run_03_questionnaire_medAssist.csv
subject_01_info.yaml
So that I cannot deduce how to rename the choice file. Will ask to Jawad...
Answer from Jawad:
This file remains consistent throughout the run, i.e. run independent. It depends only on the subject and the testing conditions. So for 2 subjects, 2 conditions, 2 runs, you can use four files only.
So far me it sounds like a subject_x_condition_y.yaml , as it is constant per run for a given subject and condition setting.
BUT we only have a condition_01.yaml.
condition.yaml:
assitance_level: 1
number_runs: 10
number_subjects: 3
force: 20
height1: 1
height2: 1.6
load: 10
velocity: 1.38
horizontalMovement: 0.1
slope: 5
subject_01_cond_01_choice_metabolicCost.yaml:
mainOption1: 1
subOption1: 2
mainOption2: 2
subOption2: 10
mainOption3: 2
subOption3: 15
Two options:
condition_01.yaml
and subject_x_condition_y.yaml
subject_x_cond_y_run_z_platformData.yaml
. If the PI manager cannot handle the 1st option right now, I would just propose to go for the 2nd option. It is a workaround to get the output compliant, but I could live with it from my side.
we already support both condition_C.yaml and subject_S_condition_C.yaml. I think we could handle even subject_S_condition_C(_xxxxxxxxxxx).yaml with a minor change. Let me try it.
I know you can handle both. The question is whether you could handle both at the same time
Of course we can do it at the same time. First we look for condition(_C).yaml (without anything bedore condition) and then we look for subject(_S)_condition(_C).yaml. The names should be renamed from subject_S_cond_C_choice_metabolicCost.yaml to subject_S_condition_C_choice_metabolicCost.yaml
Great then, I will propose this adjustment, but as files are created manually, I doubt there would be any issue.
As there is only type and as it is already implemented I propose to rename them to subject_S_condition_C.yaml. I have to check whether adding characters after _C would work (specially if they have underscores)
Ok, I wait for your final check for updating the repository acordingly then
Checked. It can be specified both subject_S_condition_C.yaml
or subject_S_condition_C_choice_metabolicCost.yaml
. When specifying inputs of the algorithm you put subject_condition.yaml
or subject_condition_choice_metabolicCost.yaml
How could I have any doubt about the robustness of your code?
It was only working with subject_S_condition_C.yaml but I have extended it. Anyway, you are right to doubt. I have a person subcontracted for doing the real time parsing. Depending on how much he/she sleeps, the PiManager could work better or worse.
I made the change, and assigned it to you for revision. Can you check it without merging ? If it is ok, I will bring the change to the origin branch first.
V0.0.1 uploaded .
ok, I will test it and change the status in eurobench_protocol
done. tested uploaded and working in the website
No image in docker_hub. There is an space for the image but no image has been uploaded.