On Mon, Oct 7, 2013 at 11:07 AM, David Knezevic
wrote:
> On Mon, Oct 7, 2013 at 10:59 AM, David Knezevic <
> [email protected]> wrote:
>
>Thanks for the head up re "git format-patch -1". I just did git diff >
>> patch.txt (like in the old svn days)
>>
>> I have the code in my dknez/l
On Mon, Oct 7, 2013 at 10:59 AM, David Knezevic
mailto:[email protected]>> wrote:
Thanks for the head up re "git format-patch -1". I just did git
diff > patch.txt (like in the old svn days)
I have the code in my dknez/libmesh fork as well, so I should've
just pointed yo
On Mon, Oct 7, 2013 at 10:59 AM, David Knezevic
wrote:
> Thanks for the head up re "git format-patch -1". I just did git diff >
> patch.txt (like in the old svn days)
>
> I have the code in my dknez/libmesh fork as well, so I should've just
> pointed you there I guess. Anyway, thanks for setting
Thanks for the head up re "git format-patch -1". I just did git diff >
patch.txt (like in the old svn days)
I have the code in my dknez/libmesh fork as well, so I should've just
pointed you there I guess. Anyway, thanks for setting up the new branch,
it'll be great to get this thing sorted so
OK, this patch has been pushed as the 'complex_io' branch.
BTW, how did you make your patch?
git format-patch -1
is probably the simplest, most terse way to make a patch file from the most
recent local commit.
The one you sent wouldn't apply with 'git am' so I used 'git apply,' but
that doesn't
I've attached a patch that I've tried for fixing output with complex
values (it doesn't work yet). The approach I've used is based on Paul's
suggestion in issue #47 on github.
I tested it with introduction_ex4 (using Exodus format) and it gives
incorrect solution fields.
It seems like the pr