I do really think the classes should be renamed. Coming from the outside I
would totally think that I need to use SerialMesh when running in serial
and ParallelMesh when running in parallel. No amount of documentation
could stop me from trying it that way first ;-)
I do somewhat agree with your reservations about "DistributedMesh"
though... but I still think it will be way better than what we have. It
doesn't necessarily map directly to something they know of... so at least
it will make them pause and try to understand what it means / implies and
read the (hopefully improved) documentation.
>From that standpoint I still kind of think "DecomposedMesh" is maybe a
little better... it lets people know right away that the mesh is being
split up. For instance: ReplicatedMesh vs. DecomposedMesh would have made
perfect sense to the guy that emailed libmesh-users today. He would have
immediately known that since he wants a copy of the mesh on every processor
that he wants to use ReplicatedMesh.
We could also go even simpler:
SerialMesh -> BasicMesh
ParallelMesh -> AdvancedMesh
That way it's obvious that one is going to be more complicated than the
other... and you should really use BasicMesh until you really have a need
to go with the more "Advanced" option...
Derek
On Thu, Mar 10, 2016 at 1:03 PM Cody Permann <codyperm...@gmail.com> wrote:
> "DistributedMesh" is good, but it might still have some of the same
> problems we encounter with the name "ParallelMesh": People might think. "Oh,
> I want distributed, I'm running on a distributed computer, or I'm running
> in distributed memory...".
>
> Perhaps half of the battle is really improving the documentation and even
> providing use cases for when you might move to "ParallelMesh". People often
> just don't have a good feel for what is big. Every once in awhile we get
> the my problem doesn't scale message on our list. Somebody is trying to
> scale a mesh with a thousand elements to several dozen processors... I have
> this link bookmarked for that case:
> http://www.mcs.anl.gov/petsc/documentation/faq.html#slowerparallel
>
> We need the same thing for when to use one mesh type over the other.
>
> Cody
>
>
> On Thu, Mar 10, 2016 at 10:56 AM Cody Permann <codyperm...@gmail.com>
> wrote:
>
>> On Thu, Mar 10, 2016 at 10:07 AM Derek Gaston <fried...@gmail.com> wrote:
>>
>>> Backwards compatibility is trivial... a typedef will work...
>>>
>>> lol... you've been watching too much Walking Dead!
>>>
>>> Any other suggestions?
>>>
>>> SerialMesh -> MemoryWastingMesh
>>>
>> +1
>>> ParallelMesh -> TimeWastingMesh
>>> +1
>>> ?
>>>
>>> Those really crack me up and they actually nail the tradeoffs perfectly!
>> However maybe the glass is half full instead:
>>
>> SerialMesh -> TimeEfficientMesh
>>
>> ParallelMesh -> SpaceEfficientMesh
>>
>> Cody
>>
>>
>>> On Thu, Mar 10, 2016 at 12:05 PM John Peterson <jwpeter...@gmail.com>
>>> wrote:
>>>
>>>> On Thu, Mar 10, 2016 at 9:59 AM, Derek Gaston <fried...@gmail.com>
>>>> wrote:
>>>>
>>>>> The time has come. There is simply too much confusion between
>>>>> ParallelMesh and SerialMesh. It seems like there's not a week that goes
>>>>> by
>>>>> that we don't get a question about using one or the other in the wrong way
>>>>> on the mailing lists (both libMesh and MOOSE).
>>>>>
>>>>> I propose this:
>>>>>
>>>>> ParallelMesh -> DontUseThisMeshUnlessYouHaveMoreThan100MillionElements
>>>>>
>>>>> SerialMesh -> ThisIsTheMeshYouReallyWantToUse
>>>>>
>>>>> Seriously though:
>>>>>
>>>>> SerialMesh -> ReplicatedMesh (get that damn Serial word out of there,
>>>>> it works in Parallel too!)
>>>>>
>>>>> ParallelMesh -> DecomposedMesh (It actually works in Serial as well!)
>>>>>
>>>>> It might also be worth adding a warning to ParallelMesh:
>>>>>
>>>>> if (parallel_n_elem() < 1e7)
>>>>> libmesh_warning("You don't have enough elements to warrant using a
>>>>> ParallelMesh. Consider using SerialMesh instead!");
>>>>>
>>>>
>>>> I wouldn't want to do this without making it backwards compatible with
>>>> the old names.
>>>>
>>>> I don't like your proposed names (decomposed == zombies?) but I'm sure
>>>> we could find others.
>>>>
>>>> --
>>>> John
>>>>
>>>
>>> ------------------------------------------------------------------------------
>>> Transform Data into Opportunity.
>>> Accelerate data analysis in your applications with
>>> Intel Data Analytics Acceleration Library.
>>> Click to learn more.
>>> http://pubads.g.doubleclick.net/gampad/clk?id=278785111&iu=/4140
>>> _______________________________________________
>>> Libmesh-devel mailing list
>>> Libmesh-devel@lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/libmesh-devel
>>>
>>
------------------------------------------------------------------------------
Transform Data into Opportunity.
Accelerate data analysis in your applications with
Intel Data Analytics Acceleration Library.
Click to learn more.
http://pubads.g.doubleclick.net/gampad/clk?id=278785111&iu=/4140
_______________________________________________
Libmesh-devel mailing list
Libmesh-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/libmesh-devel
