FEM code : issues to fix and improvements

[tmedani]

Hi all,

@ftadel in this thread, I would like to list some of the points that we need to fixe and improve for the bst-FEM code:

-1- Add the units to all the bst-gui panels regarding the FEM mesh generation (iso2mesh maxVol, ...)
-2- Add the options to refine a specific region of the mesh (for sEEG applications)
-3- Add an option to compute the compartments' volume (mm3) of the brain tissues (from the FEM mesh and even from the segmented Tissue file)
-4- Discuss and define the EEG/sEEG reference instead of using the Elec1 by default(@jcmosher)
-5- Combine the anisotropy with multiple tissues (ex : DTI for the wm and simulated for the skull)
-6- Add amplitude information on the LF visualization
-7- Save the FEM transfer matrix to the database + logfile or unique ID
-8- Write a definition file for the complete sEEG electrode (~similar as the MEG sensor file def)

I will start pushing some PR on these points asap.

[ftadel]

Are there any of these items that you need help with?

What about the two other FEM-related issues?

• FEM tutorial: Issues to fix #431
• MEG computation with FEM : memory, time, sensors, integration points & computation per block  #350

[tmedani]

Are there any of these items that you need help with?

as usual yes :) ,

point (4): we need to discuss which is the best approach to define the reference electrode.
point (7): I don't know what is the better method to save the transfer matrix to bst-database,
now it's temporarily saved as a binary file within the tmp folder when duneuro is called.

Regarding the other points, I have already some pieces of code, I need just to clean up and push asap.

• FEM tutorial: Issues to fix #431

I'm on it, with the paper

• MEG computation with FEM : memory, time, sensors, integration points & computation per block  #350

This is discussed with the Duneuro team and we are waiting for a new release where the integration points will be handled within the duneuro computation within the transfer matrix.

Thanks

[ftadel]

point (4): we need to discuss which is the best approach to define the reference electrode.

Do you mean: selecting and electrode from the interface by the user before the computation (eg. a drop-down menu in the options window), or selecting automatically during the computation?

point (7): I don't know what is the better method to save the transfer matrix to bst-database,
now it's temporarily saved as a binary file within the tmp folder when duneuro is called.

What's the point of having this file saved in the database?
Running twice the computation with different parameters?
It could be saved as a headmodel_xxxx.bin file next to the headmodel_xxxx.mat file in the database. All the deletion/creation/moving functions and processes must be modified to check for the existence of a .bin file with the same name, and apply the same operation to the side .bin as to the .mat.

We were doing that with OpenMEEG at some point, but we stopped because it was generating too many errors and huge leftover files in the database - too many problems compared to the relatively low computation time that was saved in recomputing it (a minutes).
As with DUNEuro, it can maybe save hours of computation, it might be more justified to make this effort.

However, why does it have to store it in the database, and not only in the temporary folder?
I guess if someone wants to run multiple times the same computation with slightly different parameters, this would be done in the same Brainstorm session, and therefore the files from the tmp folder could be reused directly if they are still there.

If you want to reuse an existing transfer matrix, you have to make sure all the input files are strictly the same (file names, history and computation times). One solution to make sure you are not trying to reuse a transfer matrix when running DUNEuro on a FEM mesh that was updated since the last computation, you could concatenate all the input information, and hash it to a short string, then append this string to the name of the binary file. Example:

% Compute hash from input data
hash = mlreportgen.utils.hash([FemFile, FemMat.Comment, FemMat.History{:}, FemMat.Elements(:)', FemMat.Vertices(:)']);
% Compute transfer matrix only if it is not already available in the tmp folder
TransferFile = bst_fullfile(bst_get('BrainstormTmpDir'), [duneuro_transfer_' hash '.bin']);
if ~file_exist(TransferFile)
    % Compute ...
end

Note that mlreportgen.utils.hash is available only after Matlab 2018b.
This would be an easy way for you to test this logic, but the final solution should also include a solution for older Matlab versions (probably using JAVA/SHA encoding)

Does it make sense?

[ftadel]

@tmedani Any updates on these issues?