On 7/18/12 2:51 PM, "Roy Stogner" wrote:
>> Yeah, I still use these, and would miss them if they were gone!
>
> Any chance I could talk you into not missing them? Or learn from you
> why you prefer dphidx[i][qp] over dphi[i][qp](0)? One of these days
> I'd like to add additional compile-time o
On Wed, 18 Jul 2012, Kirk, Benjamin (JSC-EG311) wrote:
Yeah, I still use these, and would miss them if they were gone!
Any chance I could talk you into not missing them? Or learn from you
why you prefer dphidx[i][qp] over dphi[i][qp](0)? One of these days
I'd like to add additional compile-
There are a couple of points that I wanted to bring up (and actually meant
to originally... need to quit sending those emails at 3AM...) about this
patch.
1. What does everyone think about deprecating the get_dxidx() etc.
functions in favor of getting the FEMap object and getting those data from
t
All,
On Wed, Jul 18, 2012 at 10:54 AM, Paul T. Bauman wrote:
> I've constructed a patch which abstracts the construction of the shape
> functions in the physical domain (assuming their initialization in the
> reference domain). The patch can be found here:
> http://users.ices.utexas.edu/~pbauman
All,
I've constructed a patch which abstracts the construction of the shape
functions in the physical domain (assuming their initialization in the
reference domain). The patch can be found here:
http://users.ices.utexas.edu/~pbauman/fe_trans.patch
The main idea is an FETransformationBase object g
Yeah, I still use these, and would miss them if they were gone!
On Jul 18, 2012, at 1:31 AM, "Paul T. Bauman"
mailto:ptbau...@gmail.com>> wrote:
On Wed, Jul 18, 2012 at 1:00 AM, Roy Stogner
mailto:royst...@ices.utexas.edu>> wrote:
Two generic reasons for storing separate scalar components:
B
