Please see the red markings in the picture, at this point the abaqus adapter is really not connected to the precice, but in my experience the precice should wait in the red and not run straight down the line, can anyone answer my question?
very thanks, I think I know what you mean, but…, I think I should described more details:
1 I do the coupling between abaqus and fluent
2 Before coupling with precice, in order to find the cause of the error, I added two lines of print statements inside the localDirectory function in ConnectionInfoPublisher.cpp in precice,as follow:
3 I ran the abaqus and fluent adapters separately, so let’s take a look at the difference in the input data of the localDirectory() function when running the abaqus and fluent adapters separately,as follow:
Well, it’s very strange that Fluent and abaqus are using the same precice function localDirectory(), and with the same input to that function, the output is different, and abaqus successfully prints the last statement “std::cout<<“p=======” <<p.string()<<std::endl;”, but Fluent is calculating “auto P=…” but Fluent is having trouble calculating “auto P=”.
ok, I’ll summarize a few of my issues and hopefully people will give me help, I’m not really sure if it’s a bug or not.
First question:
Why does abaqus work fine with the same input, but fluent doesn’t calculate “auto p=…”
Second question:
Code “auto p=…” is just splicing strings using boost library, how can this process be wrong?
Third question:
why the precice-run directory can only be generated by abaqus, but not when running the
fluent adapter?
When you start Fluent from 01fluent/, Fluent calls preCICE, which then looks for precice-config.xml in the 05test/. Similarly, when you start Abaqus from 02abaqus/, Abaqus also calls preCICE, which also looks for precice-config.xml in 05test.
I also assume that the Fluent adapter works fine (I don’t know if that’s true, it is an experimental/unmaintained adapter at the moment).
I don’t know, but you could try running Fluent inside a debugger (e.g., compile with -g, start with gdb) and try to understand where this std::bad_alloc comes from. You can set a breakpoint at localDirectory and execute the code till that point, before you step into each line. Maybe it does not even crash where you think it is crashing.
I doubt that this is the problem.
This is expected: The one participant creates the precice-run directory, where it publishes its address. The other participant then looks into that directory for that address, and connects.
very thanks.
After many tests, I finally realized that it is because of the problem of the adapter of fluent_21_2_0 version, because when running the case_2D that comes with this version
, you will also find that there will be memory problems, too bad!