On Mon, Feb 1, 2016 at 10:27 AM, David Knezevic <david.kneze...@akselos.com>
wrote:
> On Mon, Feb 1, 2016 at 12:21 PM, John Peterson <jwpeter...@gmail.com>
> wrote:
>
>>
>>
>> On Mon, Feb 1, 2016 at 10:16 AM, David Knezevic <
>> david.kneze...@akselos.com> wrote:
>>
>>> On Mon, Feb 1, 2016 at 12:13 PM, Roy Stogner <royst...@ices.utexas.edu>
>>> wrote:
>>>
>>>>
>>>> We ought to just store order internally as an int, change the existing
>>>> constructors to convert, and add new constructors that take int.
>>>> ---
>>>> Roy
>>>>
>>>
>>>
>>> Sounds good to me. The enum Order seems unnecessarily restrictive, so
>>> it'd be good to store order internally as an int.
>>>
>>> By the way, I'm not up to speed on the "sparse scalars" that John
>>> mentioned. What does that refer to exactly?
>>>
>>
>> It used to be that SCALARS had to be coupled to all other dofs in the
>> system, but I think that restriction has been relaxed.
>>
>
>
> OK, that's great. How do we specify the coupling? It'd be good to update
> systems_of_equations_ex5 to illustrate this, since that uses a SCALAR that
> only couples to the "v" dofs on one of the boundaries (in order to impose a
> "zero average y-displacement" constraint).
>
Hm, I guess it was subdomain-restricted SCALAR support I was thinking of,
84dfabe20, although the branch was called sparse_scalars.
--
John
------------------------------------------------------------------------------
Site24x7 APM Insight: Get Deep Visibility into Application Performance
APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
Monitor end-to-end web transactions and take corrective actions now
Troubleshoot faster and improve end-user experience. Signup Now!
http://pubads.g.doubleclick.net/gampad/clk?id=267308311&iu=/4140
_______________________________________________
Libmesh-devel mailing list
Libmesh-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/libmesh-devel
