Hi Felipe,
Felipe Hernandez <felipehernandezbarroso(a)gmail.com> writes:
> Sorry for being a bit unresponsive, I had
> midterms/work this week. I am currently
> spending a few hours in the airport
> waiting for a connection, so I think I can
> finish up the revisions. You can expect
> the fixes to be committed by tonight.
>
> The unit test may or may not be in today's revision, depending on how
> productive I am. I do plan to write it
> though.
I just looked at the github branch, and I didn't see any commits after
March 16, especially none of the fixes you mentioned? Did you forget to
git push?
Andreas
Felipe Hernandez <felipeh(a)MIT.EDU> writes:
> I can try to be that high tech, but I'd need a little assistance (not too much).
> Specifically, how do I send a pull request?
Easy:
- Fork the hedge repo on github.
- Push your work into a branch of that.
- Navigate to that branch on the github website.
- Click "create pull request".
- Done.
Andreas
Hi Felipe,
Felipe Hernandez <felipeh(a)MIT.EDU> writes:
> On Mar 11, 2013, at 12:01 PM, Andreas Kloeckner wrote:
>> Felipe Hernandez <felipeh(a)MIT.EDU> writes:
>>> I added the backtrace. I think that the log is somehow the problem, because
>>> when I replace it with a first-order taylor series, the operator binds successfully.
>>>
>>> If you would like the code for the flux or the stress calculation, I can give that to you
>>> as well.
>>>
>>> Thanks so much for helping, by the way!
>>
>> I think I may have fixed this particular problem in git, but without a
>> self-contained test case, I can't actually guarantee that it will go
>> through all the way. I'd be much obliged if you could share a test so
>> that I can incorporate it in the test suite. Bonus for you: your code is
>> guaranteed to keep working. :)
>>
>> Andreas
>
> I have a test written, and I think the code more or less makes sense,
> even if it is incomplete. The tutorial is not yet done, but I'm hoping I
> can finish it by next week.
Sounds good.
> How do you want me to share my code with you? Should I try to
> commit it with git?
Git's the easiest for me. A pull request on github would be really
convenient, but it's up to you if you'd like to be that high-tech.
> Also, some things you should know about the code:
> - I did do a small hack that allowed me to specify boundary conditions
> on a gmsh Mesh using the boundary mapper function instead of the tag
> mapper, but the test case I wrote is just a small mesh without any
> boundary conditions (well, I guess homogenous neumann, not that the
> solver can tell), so the code might require slight modification. Let me
> know if you have any trouble with that, I did indicate with comments what
> probably needs to change. In the mean time, I could try to make my hack
> a legitimate option.
Do try to make that hack into a legitimate option. Someone else
complained to me recently that they much preferred boundary taggers over
using gmsh to specify BCs.
> - Another thing I should mention, which you will find when you try to
> run the test, is that the neohookean material model is quite complex.
> That means that even when I do hack the log problem, I haven't been
> able to use it because I am not patient enough to wait for hedge to
> understand it (instead I use the linear elasticity model).
> So there's a chance that the code is broken in a way unrelated to the
> log. Let me know if there are any problems, so that I can
> try to work on those. I don't really know if compilation will be a problem
> on your machine, it's just that mine is 5 years old.
I see--we'll cross that bridge when we get there.
Andreas
Felipe Hernandez <felipeh(a)MIT.EDU> writes:
> Sorry, I have another question.
>
> I'm using the following code to compute the gradient:
>
> from hedge.optemplate import make_nabla
>
> nabla = make_nabla(self.dimensions)
> ij = 0
> F = make_vector_field('F', 9)
> for i in range(self.dimensions):
> for j in range(self.dimensions):
> F[ij] = nabla[j](u[i])
> ij = ij + 1
>
> Should that produce roughly what I expect, or am I way off?
As long as you're aware that this is just the element-wise polynomial
derivative, then that's correct. A real weak derivative would include
interface terms, too. See hedge.models.nd_calculus for examples.
HTH,
Andreas
Felipe Hernandez <felipeh(a)MIT.EDU> writes:
> Thanks! From what I can tell it *almost* compiles (is that the right term?).
Never thought about what word to use--I guess so. :)
> The problem I'm having is that I get the error
> "ValueError: unknown flux dependency type: log"
> From what I can tell, the problem is that I perform a natural log during the calculation.
> To do it, I created this function:
> def _do_log(x):
> from hedge.optemplate.primitives import CFunction
> return CFunction("log")(x)
> Apparently, this is not working.
>
> So is the problem in the way I compute the log, or is it more subtle?
That looks like it should work. Can you provide the full backtrace?
Andreas
Hi Felipe,
Felipe Hernandez <felipeh(a)MIT.EDU> writes:
> I'm new to hedge, and I'm trying to implement an interior penalty
> method for solid mechanics. (The DG formulation I'm using is
> available in the paper "An explicit discontinuous Galerkin method for
> non-linear solid dynamics: Formulation, parallel implementation and
> scalability properties" by Noels, Radovitzky.)
>
> I think the more "direct" way to implement this is to use the
> IPDGSecondDerivative scheme, take the gradient of the displacement,
> and then take the divergence of the stress computed from that
> displacement. I'm having trouble implementing this properly though.
> This method also wouldn't include (I'd think) the stabilization term
> using the tangent elastic moduli as described in the paper. The other
> option I thought of would be to directly implement the flux terms, but
> the problem I'm having with that is I don't know how to get the
> gradient of the displacement field in the flux operator.
If you'd like to match the scheme in the paper exactly, the safest bet
is to not use the abstract, high-level second-order operators. If you
decide to use them anyway, print the resulting optemplate (using
hedge.optemplate.tools.pretty_print_optemplate) and make sure you got
what you wanted.
If you decide to not go that route, getting the gradient of the
displacement into the flux operator is easy. Suppose you've got a flux
operator invocation somewhere along the lines of
get_flux_operator(flux)(state_vector)
and wherever you built 'flux', you started from a placeholder matching
the length of 'state_vector':
w = FluxVectorPlaceholder(7) # or whatever
Then to pass an extra bit of data (in your case, the gradient) into the
flux, just change these two to:
get_flux_operator(flux)(join_fields(state_vector, my_gradient))
and
w = FluxVectorPlaceholder(7+dim)
where dim is the length of the gradient.
Hope that helps,
Andreas
Hi,
I'm new to hedge, and I'm trying to implement an interior penalty method for solid mechanics. (The DG formulation I'm using is available in the paper "An explicit discontinuous Galerkin method for non-linear solid dynamics: Formulation, parallel implementation and scalability properties" by Noels, Radovitzky.)
I think the more "direct" way to implement this is to use the IPDGSecondDerivative scheme, take the gradient of the displacement, and then take the divergence of the stress computed from that displacement. I'm having trouble implementing this properly though. This method also wouldn't include (I'd think) the stabilization term using the tangent elastic moduli as described in the paper. The other option I thought of would be to directly implement the flux terms, but the problem I'm having with that is I don't know how to get the gradient of the displacement field in the flux operator.
Any help would be appreciated.
Thanks
- Felipe Hernández
