I have just read the gmsh manual and verified that the physical tags to
surfaces are indeed getting assigned properly. The relevant lines are 25-31
in the msh file provided above.
I have arranged these lines in a table and verified that the physical tags
are getting assigned exactly as I
I would second what the other Bruno said. I think the easiest
preconditioner to try would be an ILU preconditioner. You can play with the
fill level (start from 1 and move up from there). Make sure you set your
absolute and relative tolerance to a reasonable level though.
On Thursday, April
Hi Alex,
I’m sorry that I didn’t find the time to contribute any further to our
discussion. But I’m really glad to hear that you carried on experimenting and
ultimately found a solution to the problem that you were facing. Thank you for
sharing the solution with us. When I next have some time,
Hi Julie,
I’m glad to hear that you managed to figure out what the problem was! Thank you
for letting us know that you made progress, and that the line search part was
in fact working as expected. Good luck with solving the next part of the puzzle
:-)
Best,
Jean-Paul
> On 5. May 2021, at
Thanks to both of you!
The implementation of a own function was the best solution to my issue. In
there I basically ask the neighbor-cells and again those neighbors if the
given vertex is located on that cells. My function is a bit faster than
your suggestion Luca, but not that much.
Hi all,
just wanna give you an update. LineMinimization was doing what it is
supposed to do. The problem was p-Laplace and the configuration of a few
parameters in the code. I am facing another problem but now it is of
theoretical nature.
Thanks a lot for the reply, Jean and Bruno :)
On
On 5/4/21 6:15 PM, Abbas Ballout wrote:
I am running my code in Debug using the latest 9.3 release.
I have attached a minimal code and what it does it that it prints the
constraints.
* If BCs are applied for both parts of the system ,my output for the
constraint is:
1. 0 = 0
2.
Hi,
Thank you for taking a look. You are correct in that if I comment
out VectorTools::interpolate_boundary_values in line 320, the solution does
not change. If I understand you correctly, you are saying that the function
apply_boundary_values defined in line 553 and called in line 630 must
In addition to that, I’d suggest you use the
GridTools::Cache::get_vertex_to_cell_map class, which builds the map once, and
stores it for future reference. This one uses GridTools::vertex_to_cell_map,
which builds the map with one pass, instead of looping over all cells.
Indeed, if you want to
Bruno,
As you suggested, I was able to successfully install the release version.
Thanks!
On Tuesday, May 4, 2021 at 5:54:57 PM UTC+5:30 bruno.t...@gmail.com wrote:
> Vachan,
>
>
> On Tuesday, May 4, 2021 at 2:45:30 AM UTC-4 vachanpo...@gmail.com wrote:
>
>> Dear all,
>>
>> I am trying to do a
Hi Marc
Thank you for your constructive suggestion.
"You can disable this behavior by setting `dominate = false` (the default
value). Correct me if I'm wrong, but I think that's what you want to do."
*Yes, the extra dofs are not constrained when I changed "dominate = true "
to "dominate =
I did manage to get rid of the error and successfully run the simulation
using eclipse CDT in built debugger as illustrated in video lecture 25 by
Dr. Bangerth.So I would like to assure the developers that the issue on
this thread has been resolved.
Regards
Pushkar
On Wednesday, May 5, 2021
Thank you, Wolfgang.
I sorted it out, following the hanging node constraint sequence of
instructions.
It seems to work just fine.
*Alberto Salvadori* Dipartimento di Ingegneria Meccanica e Industriale
(DIMI)
Universita` di Brescia, via Branze 43, 25123 Brescia
Italy
tel 030 3715426
e-mail:
Hello Chong,
you've set `dominate = true` for your `FE_Nothing` element. This means that
your solution will be constrained to be continuous on interfaces with other
elements. Since `FE_Nothing` represents the zero space, all DoFs on
interfaces will be constrained to zero.
You can disable this
14 matches
Mail list logo
