Skip to content
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
Closed

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

davydden opened this issue Jan 4, 2016 · 13 comments
Assignees

Comments

@davydden
Copy link
Member

@davydden 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
Copy link
Member

@bangerth 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
Copy link
Member Author

@davydden 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
Copy link
Contributor

@oneliefleft 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
Copy link
Member Author

@davydden 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
Copy link
Contributor

@oneliefleft 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
Copy link
Member

@bangerth 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
Copy link
Member Author

@davydden 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
Copy link
Member Author

@davydden 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
Copy link
Member Author

@davydden 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
Copy link
Member Author

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

@bangerth
Copy link
Member

@bangerth 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
Copy link
Member

@bangerth 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
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
3 participants
You can’t perform that action at this time.