Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

FEM code : issues to fix and improvements #477

Open
tmedani opened this issue Dec 20, 2021 · 4 comments
Open

FEM code : issues to fix and improvements #477

tmedani opened this issue Dec 20, 2021 · 4 comments
Assignees

Comments

@tmedani
Copy link
Member

tmedani commented Dec 20, 2021

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
Copy link
Member

ftadel commented Dec 21, 2021

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

What about the two other FEM-related issues?

@tmedani
Copy link
Member Author

tmedani commented Dec 21, 2021

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.

I'm on it, with the paper

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
Copy link
Member

ftadel commented Dec 26, 2021

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
Copy link
Member

ftadel commented Jun 8, 2022

@tmedani Any updates on these issues?

@ftadel ftadel changed the title FEM code : issues to fixe and improvements FEM code : issues to fix and improvements Jun 8, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants