[Hugo]

Hi @sarah

I moved your question in a new topic.
To be honest, I am not super familiar with the details of these stats.

I would say that:
– 100 is the number of steps which are run and the digits in the table are actually average over these 100 iterations
– NUM means how many times this is computed
– TOTAL which is multiplied by 100 (10999.1) I would say this is an error, and should be 109.991)

It would be nice if you would be curious and check into the code, and even put some fix there! I am as knowledgeable as you are here 🙂

Still I hope this helps a bit!
Cheers

Hugo

[Hugo]

Hi

First, the MechanicalObject error comes from the np matrix format with …
You need to remove the ‘…’, thus your command becomes:
str(Coord.flatten()).replace('\n', '').replace('[', '').replace(']','').replace('...','')

Second, the error of the FixedConstraint comes from a problem of index, as you can see in FixedConstraint.inl line 179. Which means, you have a size problem somewhere there.

This should help, let me know if you stay stuck.
Best,

Hugo

[Hugo]

Dear @pasquale94

Many questions mean many investigation ongoing with SOFA! That’s good!
Since your question concerns the work from CSIRO and that I am not familiar with it (and apparently some error related to ‘openscad’), let me add Dr. Hockings to the discussions @NickHockings

Best

Hugo

[Hugo]

Hi @scharreyron

Could you try launching SOFA (./bin/runSofa) from the following repository: cd /Applications/runSofa.app/Contents/MacOS

Could you tell me if you still have this issue?
In my case, the default path in the MacOS binary seems to be restricted to this one (/Applications/runSofa.app/Contents/MacOS).

Looking forward to hearing from you.
Best,

Hugo

[Hugo]

Hi @outtt

Sorry I am not sure to get your point (i’m maybe too sleepy, it’s late here)
What kind of strip are you aiming at simulating? Ligaments? Could you elaborate on your use case?
Do you want to have beams connected to a surface?

Hugo

[Hugo]

Hi @yul131

So you installed Qt using the installer as described in the documentation, is that correct ?
Your CMake configuration step went well without any error output ?
So did the compilation ?
And you finally have this error at runtime ?

Could you please check each of above points, please?

Hugo

[Hugo]

Hi @stonkens

Your post was marked as spam. Sorry about the process delay.
We will get on your topic early this week.

Hugo

[Hugo]

HI @eddhoare

This topic is marked as solved, while you have not received any reply.
Is it really solved?

Best,

Hugo

[Hugo]

Hi @scharreyron

Sorry for the silence of these last days, we’ve been kept busy.
Have you solved your issue?

@guillaumeparan is the above input helping understanding the issue?

Hugo

[Hugo]

Hi @marcomag

Thank you for reporting this error.
The error looks like the constraint is not implemented for this specific template (Rigid3d). More specifically, I would guess that the matrix structure from the BTD (using the block Matrix6d) is too specific and the constraint can not be properly applied.

We would need to implement this applyConstraint() for the BTD as well, even if this is very specific to beam problems.

Thanks again for pointing this out.
I just created an issue here.

Hugo

[Hugo]

Hey @bobiko

Did Guillaume’s advice help?
Best

Hugo

[Hugo]

Hi @jerry

Regarding the WriteState it works fine for me, when running the example scene examples/Components/misc/WriteState.xml I get the resulting gravity*.data files created in my build repository.

Same for the Monitor. Have you checked in the different possible paths:
– build repository
– src root
– or the location your scene file is located

Best wishes,

Hugo

[Hugo]

Hi @jason123

Yes this is feasible, but this is unfortunately not easy. We are working on this and things should change (for the best!) by the end of the year.
You can take a look at this post.
I hope it will help.
Best,

Hugo

[Hugo]

Hi @yul131

What did you do to make it compile successfully?
What was the problem? Were you missing the dependency pack?

Best

Hugo

[Hugo]

Great @pasquale94 keep us posted about your future work!
Thanks @froy!

[Hugo]

Hi @jerry

I am not sure to understand your question.
In SOFA, both Monitor and ExportState come by default. So you should not have missed anything.

Could you share a non-working scenario please?
Best

Hugo

[Hugo]

Hi @pasquale94,

I am pretty sure there is no Cuda compatibility within the HighOrder plugin.
I will let you know when I can start the refreshing of the plugin.

Best,

Hugo

[Hugo]

Hi @enxing

I tried to send a reply yesterday evening, but it apparently did not work.
It seems you are using the v19.12 release. Since then, I think this has been fixed in the master branch of SOFA (see PR #1313). The path to the pluginManager.cpp was incomplete, prefix was empty and not set to _d in debug mode.

This will therefore be fixed in the next release v20.06.

Best,

Hugo

[Hugo]

Argh @pasquale94, I am sorry you are using several plugins (OpenCL) which have not been updated for some time. It’s actually the case for the HighOrder plugin, but I can surely help on this one.

I can try to clone its latest version with the latest SOFA version and make an update. But I might not have the time right in the coming days. Otherwise I could guide you.

Best wishes,

Hugo

[Hugo]

Hi @sarah

Thanks for the interesting link!
For your information a BDF2 scheme has already been implemented. One is available here: ExplicitBDFSolver

If you want to analyze this dissipation effect, clearly no additional damping should be set up. Otherwise the interpretation will be complicated. I need some more time to look at your scene. Let me get back to you asap.

Best,

Hugo

[Hugo]

Hi @pasquale94

Sorry for the delayed reply.
This is due to the fact that the constraint resolution has no CUDA version (CudaVec instantiation) in the open-source version of SOFA. However, it does exist in some private plugins.

I am campaigning for a release in open-source of this part as well. But I have not succeeded yet. Let me try to chat with researchers about this (I will have a meeting next week with them) and get back to you.

Best wishes,

Hugo

[Hugo]

Hi @enxing

My first reply would be to ask: why de-activating nodes?
I would say that due to de-activation of the nodes, the initialization of the MeshSkeletonization goes wrong. What happens if you just remove those two nodes?

Best,

Hugo

[Hugo]

Welcome on the forum @jerry!
My apologies for the late reply, we’ve been kept busy these last days due to the bi-annual Technical Committee of SOFA.

And congrats @sarah for the good reply.
Let us know @jerry if you need any further assistance.

Best,

Hugo

[Hugo]

Hi @rainvector and @sarah

Well done @sarah for your answers.
1. yes, .py scenes can be directly loaded
2. RequiredPlugin (be careful in the typos, you wrote it wrong: ReGquiredPlugin) must be added when using codes which are not in the core of SOFA, or which were modularized. Follow the error messages for this.
3. See the SofaPython.pdf in the plugin applications/plugins/SofaPython repository. Take a look also to the examples/ folder in this repository.

NOTE: this plugin will be deprecated starting from v20.06 since Python 2.7 is deprecated. A new plugin is now available: SofaPython3. More information and documentation on the transition will soon be made available.

Best wishes,

Hugo

[Hugo]

Hi @sarah

Good to see your further investigations!
Could you explain why you used a non-zero Rayleigh stiffness? this will cause damping.
Did you set this Rayleigh coefficient in the integration scheme?

Best,

Hugo

PS: what was exactly the question btw?

[Author]

Posts