# Linear problem depending on a nonlinear solution and an eigenmode, in parallel

**URL:** <https://community.freefem.org/t/linear-problem-depending-on-a-nonlinear-solution-and-an-eigenmode-in-parallel/1638>\
**Category:** General Discussion\
**Created:** [April 1, 2022, 9:16am UTC](https://community.freefem.org/t/linear-problem-depending-on-a-nonlinear-solution-and-an-eigenmode-in-parallel/1638 "2022-04-01T09:16:26Z")\
**Posts on this page:** 7\
**Page:** 1

<div class="post-metadata">

**Author:** ![etj](https://avatars.discourse-cdn.com/v4/letter/e/a698b9/32.png) [@etj](https://community.freefem.org/u/etj)\
**Post date:** [April 1, 2022, 9:16am UTC](https://community.freefem.org/t/linear-problem-depending-on-a-nonlinear-solution-and-an-eigenmode-in-parallel/1638/1 "2022-04-01T09:16:26Z")

</div>

Hello,

I am using two codes, in parallel:

- one to solve with PETSc (`SNESSolve`) a nonlinear problem → let’s call the solution u,
- one to solve with SLEPc complex (`EPSSolve`) an eigenvalue problem that depends on u → let’s call the eigenmode v.

This is working correctly.

Now, I would like to use a third code to solve another (linear) problem that depends on both u and v. I have tried to define and solve the problem naively with `problem`. I do obtain a solution, but it seems that the original partition is not preserved correctly: saving the solution with `savevtk` and visualizing it in Paraview shows something that is messed up (I’m using the exact same `savevtk` command as for u and v).

I’m not sure what is the best way to do that. Should I use `varf` instead of `problem`? Do I need PETSc? Some advice and/or an example would be very helpful.

Thank you!

---

<div class="post-metadata">

**Author:** ![prj](https://avatars.discourse-cdn.com/v4/letter/p/ecae2f/32.png) [@prj](https://community.freefem.org/u/prj)\
**Post date:** [April 1, 2022, 1:56pm UTC](https://community.freefem.org/t/linear-problem-depending-on-a-nonlinear-solution-and-an-eigenmode-in-parallel/1638/2 "2022-04-01T13:56:26Z")

</div>

It all depends on what you are solving, how you are saving `u` and `v`, so on and so forth. There are too little details in your question to give you an appropriate answer. You could just do as in [FreeFem-sources/navier-stokes-2d-PETSc.edp at master · FreeFem/FreeFem-sources · GitHub](https://github.com/FreeFem/FreeFem-sources/blob/master/examples/hpddm/navier-stokes-2d-PETSc.edp#L107-L109) and [FreeFem-sources/navier-stokes-2d-SLEPc-complex.edp at master · FreeFem/FreeFem-sources · GitHub](https://github.com/FreeFem/FreeFem-sources/blob/master/examples/hpddm/navier-stokes-2d-SLEPc-complex.edp#L21-L24). In your third script, use the same routines as in `navier-stokes-2d-SLEPc-complex.edp`.

---

<div class="post-metadata">

**Author:** ![etj](https://avatars.discourse-cdn.com/v4/letter/e/a698b9/32.png) [@etj](https://community.freefem.org/u/etj)\
**Post date:** [April 1, 2022, 2:45pm UTC](https://community.freefem.org/t/linear-problem-depending-on-a-nonlinear-solution-and-an-eigenmode-in-parallel/1638/3 "2022-04-01T14:45:45Z")

</div>

Thank you for the prompt reply.

I’m trying to follow exactly `navier-stokes-2d-SLEPc-complex.edp`. In line 19, does it make a difference whether one uses `mesh Th;` or `meshN Th;`? In the latter case, line 21 `loadDmesh(Th, ...)` works, but in the former case it yields an error:

> – FreeFem++ v4.9 (Fri Jun 18 14:45:02 CEST 2021 - git v4.9)  
> Load: lg\_fem lg\_mesh lg\_mesh3 eigenvalue parallelempi  
> load: init metis (v 5 )  
> error operator = PPKN5Fem2D4MeshE, N5Fem2D5Mesh3E  
> (…)  
> Error line number 465, in file macro: loadDmesh in /home/FreeFem/lib/ff++/4.9/idp/macro\_ddm.idp, before token ;

---

<div class="post-metadata">

**Author:** ![prj](https://avatars.discourse-cdn.com/v4/letter/p/ecae2f/32.png) [@prj](https://community.freefem.org/u/prj)\
**Post date:** [April 1, 2022, 3:09pm UTC](https://community.freefem.org/t/linear-problem-depending-on-a-nonlinear-solution-and-an-eigenmode-in-parallel/1638/4 "2022-04-01T15:09:52Z")

</div>

`meshN` is a template-like type that will automatically translate to `mesh` or `mesh3`, depending on whether you define `macro dimension()2//` or `macro dimension()3//` before the inclusion of `macro_ddm.idp`. So, yes, it makes a difference if you are doing 3D. Otherwise, no difference. The type `N5Fem2D5Mesh3E` from your log indicates that you are doing 3D, so switch to either `meshN Th` or `mesh3 Th`.

---

<div class="post-metadata">

**Author:** ![etj](https://avatars.discourse-cdn.com/v4/letter/e/a698b9/32.png) [@etj](https://community.freefem.org/u/etj)\
**Post date:** [April 1, 2022, 4:32pm UTC](https://community.freefem.org/t/linear-problem-depending-on-a-nonlinear-solution-and-an-eigenmode-in-parallel/1638/5 "2022-04-01T16:32:57Z")

</div>

Thank you, that makes perfect sense.

1. Now I’m trying to solve the linear system. What should I use? (You suggested I use the same routines as in `navier-stokes-2d-SLEPc-complex.edp`, but those are for an eigenvalue problem. And those in `navier-stokes-2d-PETSc.edp` are for a non-linear system.)

2. I don’t seem to be able to mix real and complex quantities. In my case u is real and v is complex. Should I define everything as complex?

---

<div class="post-metadata">

**Author:** ![prj](https://avatars.discourse-cdn.com/v4/letter/p/ecae2f/32.png) [@prj](https://community.freefem.org/u/prj)\
**Post date:** [April 1, 2022, 6:25pm UTC](https://community.freefem.org/t/linear-problem-depending-on-a-nonlinear-solution-and-an-eigenmode-in-parallel/1638/6 "2022-04-01T18:25:08Z")

</div>

1. `KSPSolve()` or `^-1` directly.
2. if you want everything in a single script, then yes, you’ll need to stick to complexes all the way.

---

<div class="post-metadata">

**Author:** ![etj](https://avatars.discourse-cdn.com/v4/letter/e/a698b9/32.png) [@etj](https://community.freefem.org/u/etj)\
**Post date:** [April 4, 2022, 8:56pm UTC](https://community.freefem.org/t/linear-problem-depending-on-a-nonlinear-solution-and-an-eigenmode-in-parallel/1638/7 "2022-04-04T20:56:14Z")

</div>

Thank you, `KSPSolve()` seems to be working!
