kit-ibt / cobiveco Goto Github PK

I was able to build and install cobivecoX on a windows machine with all dependencies. The problem I run into immediately is that the dependency checking in th ebase cobiveco class. The windows files have an .exe extension but the dependancy check only looks for the mmg appluications without the .exe extension, and failes if the .exe are present instead. I was able to fix this using the following:

if ispc
    if ~exist([mpath '/../dependencies/mmg/build/bin/mmg3d_O3.exe'], 'file')
        error('Dependency ''mmg'' not found. Run dependencies/install_cobiveco.sh to install.');
    end
else
    if ~exist([mpath '/../dependencies/mmg/build/bin/mmg3d_O3'], 'file')
        error('Dependency ''mmg'' not found. Run dependencies/install_cobiveco.sh to install.');
    end
end

The next problem I have is when running the example_geo1.m
It fails at the computeHeartAxisAndApex.m, specifically at line 51:

if o.cfg.CobivecoX == true
    pBase = double(o.m1.sur.points((o.m1.sur.pointData.class == 5|o.m1.sur.pointData.class == 6),:));
else

where pbase comes up as an empty array.
If I change the configuration to have CobivecoX as false, then the example succeeds without issue. So it seems that the cobivecoX is not compatible with the geo1 example.

-Jake Bergquist
[email protected]

In the computeRotationalBridges method, the solveTrajectDist function is called to solve the trajectory distance equation in calculating the rotational coordinates. This uses the ichol_autocomp function to compute a precondition matrix based on the Incomplete Cholesky factorization of the gradient operator matrix of the valve bridge. This factorization seems to fail in some cases (unclear why) and if removed the resulting solution is either unaffected or in some cases improved.

I am having trouble on a mesh that has worked in the past. It is failing to identify the path along the surface to find the cutoff for the LV bridge. The starting points all look fine:

However, there is no path generated for the LV bridge closest to the TV:

I am trying to dig into the createGraphandSplitMesh.m. It is failing to find a path on line 176:

path1MvAv = shortestpath(GsubLv, nodeIndexLocalMvMin80, nodeIndexLocalAv80);

I suspect it has to do with how the GsubLv was clipped. The septum definition on this mesh does not look ideal:

However, I am not sure what to change to make that septum classification more reasonable near the septal side of the MV

Hi,
thanks so much for providing this amazing tools.
For some meshes, I encounter the issue that lambda in computeApicobasal.m cannot be optimized, which sometimes can lead to an error in the following function using pcg which is not converging and hence generation of the apicobasal coordinate is failing.
I wanted to ask, if you have a hint for a better initial guess for lambda, to improve the optimization or another idea for a default value to fall back to.
I checked different thresholds and increased the number of iterations for the optimization but without any luck.
Maybe you have encountered that issue before or have a better guess.

Thanks so much for your time and have a nice day!

Below is the code snipped I am referring to:

% half-width at half-maximum of the point spread function of the operator
% inv(speye(size(L))+lambda*(L'*L))
hwhm = mean(abLength)/100;
lambda = 1.58*hwhm^3.57;
lambda = numel(abSmoothCl)/numel(ab)*lambda;
fprintf('\n0\t%.3e\n', lambda);

b = M'*abSmoothCl + eta*E'*baseVal;
MM = M'*M + eta*(E'*E);
LL = L'*L;
extrapMisfit = o.cfg.abExtrapSmooth/100;

try
    [~,flag,iter] = secant(@objFun, 1e-1*lambda, lambda, 1e-2*extrapMisfit);
    if flag
        warning('Secant stopped at iteration %i without converging.', iter);
    end
catch err
    disp(getReport(err, 'extended', 'hyperlinks', 'off'));
    warning('Optimization of lambda failed. Using default value instead.');
    objFun(lambda);
endcomputeApicobasal.m

I seem to be running across an issue in the definition of the bridges between valves. For example, the TV to PV bridge is clipped using the paths defined in the image below. On the epicardium it seems that the distance threshold used to define the paths was insufficient to fully cut the bridge as there is a gap in the path.

The paths on the endocardium appear to be contiguous, but when they are projected to the epicardium they are discontinuous.
endo paths:

Epi points:

The defineBridgesShortestPath.m function seems to take this into account, on line 107:
% use tenths percentile as threshold for distance search
But it seems that the tenths percentile is not enough in this case. Any suggestions on how to resolve this would be appreciated.

There are a few places throughout the code that write out debug outputs which, if the export level is set to 1, are not actually set and therefore fail. One example is in computeApicobasalVentricles.m Here it writes out a debug output of the apicobasal coordinate using

vtkWrite(o.m1Ventricles.debug, sprintf('%so.m1VentriclesFinalAb.vtu', o.cfg.outPrefix));

However, if export level is set to 1 this will fail because 0.m1Ventricles.debug will have no points or cells. This is because in preparemesh1.m o.m1.debug is set to be the o.m1.vol only if export level >1:

if o.cfg.exportLevel > 1
    o.m1.debug = o.m1.vol;
    o.m1.debug.pointData.surClass = repmat(uint8(0),size(o.m1.debug.points,1),1);
    o.m1.debug.pointData.surClass(o.m1.surToVol) = o.m1.sur.pointData.class;
end

There are a few other spots around the code that do something similar, and even at export level 1, many many extra files are written that are not needed.

meshio (https://github.com/nschloe/meshio) is needed for some parts of createBoundarySurfacesAB.m to function. It should be installed in the base conda environment but it is not included in the requirements.txt

It looks like the example_CobivecoX.m example script is missing the required/expected geometry files. In the script the following is set as the setup for cobivecox:

in Cobiveco\examples\example_CobivecoX.m:

% c = cobiveco(struct('inPrefix','geo2/geo2', 'outPrefix','result_geo2/', 'exportLevel',3));
c = cobiveco(struct('inPrefix','meanTOF/meanTOF', 'outPrefix','result_meanTOF/', 'exportLevel',3, 'maxit', 4000));

The commented line referring to geo2 would likely not work as geo2 is missing definitions of the valves, needed for cobivecoX. The second line which looks for "meanTOF/meanTOF" results in an error because there is no meanTOF folder int he examples directory.

The main problem I am having is that I wanted to find an example definition of each of the inputs for cobivecoX so I could replicate it with my own models. It is not clear how the valves need to be defined. Should the valve.vtu files include just the ring of the valve annulus? Can it be a surface of the valve plane? I figure these questions would be answered if I had a working cobivecoX example.

Thanks for your help!

-Jake Bergquist
[email protected]