New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Make deal.II uniformly compatible with complex-valued vectors #2033

Closed
davydden opened this Issue Jan 4, 2016 · 13 comments

Comments

Projects
None yet
3 participants
@davydden
Member

davydden commented Jan 4, 2016

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

Also related to #1894.

@davydden davydden added the Enhancement label Jan 4, 2016

@davydden davydden self-assigned this Jan 4, 2016

@bangerth

This comment has been minimized.

Show comment
Hide comment
@bangerth

bangerth Feb 19, 2016

Member

@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.

Member

bangerth commented Feb 19, 2016

@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

This comment has been minimized.

Show comment
Hide comment
@davydden

davydden Feb 19, 2016

Member

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).

Member

davydden commented Feb 19, 2016

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

This comment has been minimized.

Show comment
Hide comment
@oneliefleft

oneliefleft Feb 19, 2016

Contributor

@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).

Contributor

oneliefleft commented Feb 19, 2016

@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

This comment has been minimized.

Show comment
Hide comment
@davydden

davydden Feb 19, 2016

Member

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

Member

davydden commented Feb 19, 2016

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

@oneliefleft

This comment has been minimized.

Show comment
Hide comment
@oneliefleft

oneliefleft Feb 19, 2016

Contributor

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).

Contributor

oneliefleft commented Feb 19, 2016

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

This comment has been minimized.

Show comment
Hide comment
@bangerth

bangerth Feb 19, 2016

Member

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.

Member

bangerth commented Feb 19, 2016

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

This comment has been minimized.

Show comment
Hide comment
@davydden

davydden Feb 19, 2016

Member

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.

Member

davydden commented Feb 19, 2016

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

This comment has been minimized.

Show comment
Hide comment
@davydden

davydden Feb 19, 2016

Member

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.

Member

davydden commented Feb 19, 2016

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

This comment has been minimized.

Show comment
Hide comment
@davydden

davydden Feb 21, 2016

Member

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...

Member

davydden commented Feb 21, 2016

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

This comment has been minimized.

Show comment
Hide comment
@davydden

davydden Feb 22, 2016

Member

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.

Member

davydden commented Feb 22, 2016

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.

@davydden

This comment has been minimized.

Show comment
Hide comment
@davydden

davydden Feb 28, 2016

Member

i created issues for critical modifications which are still to be done.

Member

davydden commented Feb 28, 2016

i created issues for critical modifications which are still to be done.

@davydden davydden changed the title from [PETSc] add complex-value support to add complex-value support for PETSc Feb 13, 2017

@bangerth bangerth changed the title from add complex-value support for PETSc to Make deal.II uniformly compatible with complex-valued vectors Nov 1, 2017

@bangerth

This comment has been minimized.

Show comment
Hide comment
@bangerth

bangerth Nov 1, 2017

Member

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.

Member

bangerth commented Nov 1, 2017

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

This comment has been minimized.

Show comment
Hide comment
@bangerth

bangerth Nov 5, 2017

Member

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

Member

bangerth commented Nov 5, 2017

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment