Make deal.II uniformly compatible with complex-valued vectors

[davydden]

move what's left from complex branch and perhaps augment configuration system.

Also related to #1894.

[bangerth]

@davydden -- can you summarize what's left to merge? I fear that the longer we wait with this, the harder it will become to apply these patches.

[davydden]

as far as i recall, the only useful thing left are unit tests.
All the important stuff, hopefully, was refactored and introduced to deal.II in spring last year.
One would need to try compiling deal.ii with, say, complex PETSc and mask, for now, what won't compile (like DataOut).

[oneliefleft]

@davydden We should mask DataOut and get on with the rest. I managed a
dirty hack to get DataOut working with complex a few years ago, but never
patched it in. I can try to revive that code, but I can not promise it will
happen any time soon. :-( I am working on my thesis... :-)

I will check the the compilation of deal.II with complex PETSc during the
next week (SLEPc is easy). That I can promise.

2016-02-19 19:14 GMT+01:00 Denis Davydov notifications@github.com:

as far as i recall, the only useful thing left are unit tests.
All the important stuff, hopefully, was refactored and introduced to
deal.II in spring last year.
One would need to try compiling deal.ii with, say, complex PETSc and mask,
for now, what won't compile (like DataOut).

—
Reply to this email directly or view it on GitHub
#2033 (comment).

[davydden]

i think the easiest way to mask is to have explicit instantiations for non-working classes / functions when complex-valued PETSc is there.

[oneliefleft]

Originally I masked functions or classes (that don't work) by using #ifdef
macros. Explicit instantiations that throw an exception is a nice idea.
What do we think about that?

2016-02-19 19:38 GMT+01:00 Denis Davydov notifications@github.com:

i think the easiest way to mask is to have explicit instantiations for
non-working classes / functions when complex-valued PETSc is there.

—
Reply to this email directly or view it on GitHub
#2033 (comment).

[bangerth]

On 02/19/2016 12:47 PM, Toby D. Young wrote:

Originally I masked functions or classes (that don't work) by using #ifdef
macros. Explicit instantiations that throw an exception is a nice idea.
What do we think about that?

I think that's a good idea that at least lets us pass the compilation
phase. I'm still in favor of the full plan laid out in #1894, though.

[davydden]

I think that's a good idea that at least lets us pass the compilation
phase. I'm still in favor of the full plan laid out in #1894, though.

those are not mutually exclusive ;-) I would start with compilation and create issues for everything that does not work to be fixed later.

[davydden]

In the last working version in my branch I modified configuration system to split vectors. That was done partly to mask things which do not work (i modified instantiation scripts for some classes to run for real-valued vectors only).

Thinking about it now, explicit instantiation should be easier way of doing it.

[davydden]

I started looking at it... Explicit instantiations are not enough to fix it, i will bring the modified /template-arguments.in and create a PR, hopefully soon...

[davydden]

ok, i have a compilable/linkable version of deal.ii with complex-valued PETSc.
Will be creating PRs with necessary changes now...

Here are things which are "masked" (will create a PR with the masked things after all proper fixes are merged) :

• DataEntry<>::get_function_xyz() (related to DataOut)
• PointValueHistory
• DerivativeApproximation

That's fewer than what I expected. The latter two are optional.

[bangerth]

For reference, I'm now at a point where I can instantiate everything with complex-valued vectors. Patches (in addition to those already merged/proposed) forthcoming.

[bangerth]

I think this closes the current issue. There are some read-guard action items, but they are tracked in separate PRs.