# encoding: utf-8 # module vtkmodules.vtkIOParallelLSDyna # from C:\Users\xukai\Downloads\发票2\venv\Lib\site-packages\vtkmodules\vtkIOParallelLSDyna.cp311-win_amd64.pyd # by generator 1.147 # no doc # imports import vtkmodules.vtkIOLSDyna as __vtkmodules_vtkIOLSDyna # no functions # classes class vtkPLSDynaReader(__vtkmodules_vtkIOLSDyna.vtkLSDynaReader): """ vtkPLSDynaReader - Read LS-Dyna databases (d3plot) in parallel Superclass: vtkLSDynaReader This filter reads LS-Dyna databases in parallel. The Set/GetFileName() routines are actually wrappers around the Set/GetDatabaseDirectory() members; the actual filename you choose is irrelevant -- only the directory name is used. This is done in order to accommodate ParaView. @attention LSDyna files contain 3 different types of sections: control, data, and state. Control sections contain constants that describe the type of simulation data in a file or group of files. Data sections contain simulation information that is invariant across individual time steps (but can vary when a mesh adaptation occurs). This information includes material, connectivity, and undeformed geometry. Finally, state data is information that varies with each time step. Unless a mesh adaptation occurs, there will be a single control and data section, and they will be located at the start of the database (the first file). @attention In their infinite wisdom, LSDyna developers decided to split simulation data into multiple files, each no larger than some predetermined limit. Each file can contain one section, a partial section (if it would not fit into a single file), or multiple sections. Files are padded with zeros so that their lengths will be multiples of 512*512. The size of each section is determined by constants in the control and data sections, which means that these must be parsed carefully in order to correctly locate desired information. Unfortunately, the constants are not terribly well-documented and in some cases the documentation is in error. @par "Open Issues": The LS-Dyna file format document leaves a good bit open to interpretation. In addition to the "documentation vs. files in the wild" issues there are also implementation problems. @par "Open Issues": - Where exactly may breaks to a new file occur in the pre-state information? At each section? - Will state data sections (node/cell data, element deletion, sph data, rigid body motion) be moved to the beginning of a new file if their data will be too large for a given file, or are all the sections counted together as a single state (makes more sense for keeping time word at start of every file). The questions above arise because the docs (p. 3) state "There are 3 sections in this database." but then call many smaller pieces of data "sections". Should they be subsections? The docs are quiet about whether the second section (of 3) is ever split across multiple files and, if so, whether it is done at (sub)section boundaries when possible or just wherever it needs to occur. - How many components does Eddy Viscosity have? It's shown as 7 bits in NCFDV1 which makes no sense at all. - Why is NARBS larger than 10+NUMNP+NEL8+NEL2+NEL4+NELT (which is the value specified by the documentation)? Obviously, NARBS is definitive, but what are the extra numbers at the end? - Is there a difference between rigid body elements NUMRBE and rigid road surfaces? It appears that the nodes and connectivity of the road surface are given separately (p.13) while on p.7 the Material Type Data subsection says that shells in a rigid body will just have a certain material ID but be interspersed among deformable shell elements. - Word 37 of the control section serves two possible purposes... it can mean NMSPH or EDLOPT. I assume that different versions of the code use that word differently. How do we know the difference? - It's unclear how much state isn't stored when a shell element is marked as rigid. Specifically, is element deletion data stored for rigid shells? Page 21 of the spec is mute on this. - The loop to read cell User IDs won't work if Rigid Body and Shell elements are interleaved (which I now believe they are). @par "Open Issues": On the VTK side of things: - The reader doesn't handle crack files (d3crck) - The reader doesn't handle interface force files (no default name) - The reader doesn't handle time history (abbreviated output) files (d3thdt) - The reader doesn't handle dynamic relaxation files (d3drfl) - The reader doesn't handle reduced parts (state for a subset of parts) files (d3part) - The reader doesn't handle mode shape files (d3eigv) - The reader doesn't handle equilibrium iteration files (d3iter) - The reader doesn't handle extra time data files (d3xtf) - The reader doesn't handle printer files (d3hsp) - The reader doesn't handle modal neutral files (d3mnf) - The reader doesn't handle packed connectivity. - The reader doesn't handle adapted element parent lists (but the 2002 specification says LSDyna doesn't implement it). - All the sample datasets have MATTYP = 0. Need something to test MATTYP = 1. - I have no test datasets with rigid body and/or road surfaces, so the implementation is half-baked. - It's unclear how some of the data should be presented. Although blindly tacking the numbers into a large chuck of cell data is better than nothing, some attributes (e.g., forces & moments) lend themselves to more elaborate presentation. Also, shell and thick shell elements have stresses that belong to a particular side of an element or have a finite thickness that could be rendered. Finally, beam elements have cross sections that could be rendered. Some of these operations require numerical processing of the results and so we shouldn't eliminate the ability to get at the raw simulation data. Perhaps a filter could be applied to "fancify" the geometry. """ def CanReadFile(self, fname): # real signature unknown; restored from __doc__ """ CanReadFile(self, fname:str) -> int C++: int CanReadFile(const char *fname) override; Determine if the file can be read with this reader. """ return 0 def GetController(self): # real signature unknown; restored from __doc__ """ GetController(self) -> vtkMultiProcessController C++: virtual vtkMultiProcessController *GetController() """ pass def GetNumberOfGenerationsFromBase(self, type): # real signature unknown; restored from __doc__ """ GetNumberOfGenerationsFromBase(self, type:str) -> int C++: vtkIdType GetNumberOfGenerationsFromBase(const char *type) override; Given the name of a base class of this class type, return the distance of inheritance between this class type and the named class (how many generations of inheritance are there between this class and the named class). If the named class is not in this class's inheritance tree, return a negative value. Valid responses will always be nonnegative. This method works in combination with vtkTypeMacro found in vtkSetGet.h. """ return 0 def GetNumberOfGenerationsFromBaseType(self, type): # real signature unknown; restored from __doc__ """ GetNumberOfGenerationsFromBaseType(type:str) -> int C++: static vtkIdType GetNumberOfGenerationsFromBaseType( const char *type) Given a the name of a base class of this class type, return the distance of inheritance between this class type and the named class (how many generations of inheritance are there between this class and the named class). If the named class is not in this class's inheritance tree, return a negative value. Valid responses will always be nonnegative. This method works in combination with vtkTypeMacro found in vtkSetGet.h. """ return 0 def IsA(self, type): # real signature unknown; restored from __doc__ """ IsA(self, type:str) -> int C++: vtkTypeBool IsA(const char *type) override; Return 1 if this class is the same type of (or a subclass of) the named class. Returns 0 otherwise. This method works in combination with vtkTypeMacro found in vtkSetGet.h. """ return 0 def IsTypeOf(self, type): # real signature unknown; restored from __doc__ """ IsTypeOf(type:str) -> int C++: static vtkTypeBool IsTypeOf(const char *type) Return 1 if this class type is the same type of (or a subclass of) the named class. Returns 0 otherwise. This method works in combination with vtkTypeMacro found in vtkSetGet.h. """ return 0 def NewInstance(self): # real signature unknown; restored from __doc__ """ NewInstance(self) -> vtkPLSDynaReader C++: vtkPLSDynaReader *NewInstance() """ return vtkPLSDynaReader def SafeDownCast(self, o): # real signature unknown; restored from __doc__ """ SafeDownCast(o:vtkObjectBase) -> vtkPLSDynaReader C++: static vtkPLSDynaReader *SafeDownCast(vtkObjectBase *o) """ return vtkPLSDynaReader def SetController(self, c): # real signature unknown; restored from __doc__ """ SetController(self, c:vtkMultiProcessController) -> None C++: void SetController(vtkMultiProcessController *c) Set/Get the communicator object. By default we use the world controller """ pass def __delattr__(self, *args, **kwargs): # real signature unknown """ Implement delattr(self, name). """ pass def __getattribute__(self, *args, **kwargs): # real signature unknown """ Return getattr(self, name). """ pass def __init__(self, *args, **kwargs): # real signature unknown pass @staticmethod # known case of __new__ def __new__(*args, **kwargs): # real signature unknown """ Create and return a new object. See help(type) for accurate signature. """ pass def __repr__(self, *args, **kwargs): # real signature unknown """ Return repr(self). """ pass def __setattr__(self, *args, **kwargs): # real signature unknown """ Implement setattr(self, name, value). """ pass def __str__(self, *args, **kwargs): # real signature unknown """ Return str(self). """ pass __this__ = property(lambda self: object(), lambda self, v: None, lambda self: None) # default """Pointer to the C++ object.""" __dict__ = None # (!) real value is 'mappingproxy({\'__vtkname__\': \'vtkPLSDynaReader\', \'IsTypeOf\': , \'IsA\': , \'SafeDownCast\': , \'NewInstance\': , \'GetNumberOfGenerationsFromBaseType\': , \'GetNumberOfGenerationsFromBase\': , \'CanReadFile\': , \'SetController\': , \'GetController\': , \'__new__\': , \'__repr__\': , \'__str__\': , \'__getattribute__\': , \'__setattr__\': , \'__delattr__\': , \'__dict__\': , \'__this__\': , \'__doc__\': \'vtkPLSDynaReader - Read LS-Dyna databases (d3plot) in parallel\\n\\nSuperclass: vtkLSDynaReader\\n\\nThis filter reads LS-Dyna databases in parallel.\\n\\nThe Set/GetFileName() routines are actually wrappers around the\\nSet/GetDatabaseDirectory() members; the actual filename you choose is\\nirrelevant -- only the directory name is used. This is done in order\\nto accommodate ParaView.\\n\\n@attention LSDyna files contain 3 different types of sections:\\ncontrol, data, and state. Control sections contain constants that\\ndescribe the type of simulation data in a file or group of files. \\nData sections contain simulation information that is invariant across\\nindividual time steps (but can vary when a mesh adaptation occurs). \\nThis information includes material, connectivity, and undeformed\\ngeometry. Finally, state data is information that varies with each\\ntime step. Unless a mesh adaptation occurs, there will be a single\\ncontrol and data section, and they will be located at the start of\\nthe database (the first file).\\n\\n@attention In their infinite wisdom, LSDyna developers decided to\\nsplit simulation data into multiple files, each no larger than some\\npredetermined limit. Each file can contain one section, a partial\\nsection (if it would not fit into a single file), or multiple\\nsections. Files are padded with zeros so that their lengths will be\\nmultiples of 512*512. The size of each section is determined by\\nconstants in the control and data sections, which means that these\\nmust be parsed carefully in order to correctly locate desired\\ninformation. Unfortunately, the constants are not terribly\\nwell-documented and in some cases the documentation is in error.\\n\\n@par "Open Issues": The LS-Dyna file format document leaves a good\\nbit open to interpretation. In addition to the "documentation vs.\\nfiles in the wild" issues there are also implementation problems.\\n\\n@par "Open Issues":\\n- Where exactly may breaks to a new file occur in the pre-state\\n information? At each section?\\n- Will state data sections (node/cell data, element deletion, sph\\n data, rigid body motion) be moved to the beginning of a new file if\\ntheir data will be too large for a given file, or are all the\\n sections counted together as a single state (makes more sense for\\n keeping time word at start of every file). The questions above\\n arise because the docs (p. 3) state "There are 3 sections in this\\n database." but then call many smaller pieces of data "sections".\\n Should they be subsections? The docs are quiet about whether the\\n second section (of 3) is ever split across multiple files and, if\\n so, whether it is done at (sub)section boundaries when possible or\\n just wherever it needs to occur.\\n- How many components does Eddy Viscosity have? It\\\'s shown as 7 bits\\n in NCFDV1 which makes no sense at all.\\n- Why is NARBS larger than 10+NUMNP+NEL8+NEL2+NEL4+NELT (which is the\\n value specified by the documentation)? Obviously, NARBS is\\n definitive, but what are the extra numbers at the end?\\n- Is there a difference between rigid body elements NUMRBE and rigid\\n road surfaces? It appears that the nodes and connectivity of the\\n road surface are given separately (p.13) while on p.7 the Material\\n Type Data subsection says that shells in a rigid body will just\\n have a certain material ID but be interspersed among deformable\\n shell elements.\\n- Word 37 of the control section serves two possible purposes... it\\n can mean NMSPH or EDLOPT. I assume that different versions of the\\n code use that word differently. How do we know the difference?\\n- It\\\'s unclear how much state isn\\\'t stored when a shell element is\\n marked as rigid. Specifically, is element deletion data stored for\\n rigid shells? Page 21 of the spec is mute on this.\\n- The loop to read cell User IDs won\\\'t work if Rigid Body and Shell\\n elements are interleaved (which I now believe they are).\\n\\n@par "Open Issues": On the VTK side of things:\\n- The reader doesn\\\'t handle crack files (d3crck)\\n- The reader doesn\\\'t handle interface force files (no default name)\\n- The reader doesn\\\'t handle time history (abbreviated output) files\\n (d3thdt)\\n- The reader doesn\\\'t handle dynamic relaxation files (d3drfl)\\n- The reader doesn\\\'t handle reduced parts (state for a subset of\\n parts) files (d3part)\\n- The reader doesn\\\'t handle mode shape files (d3eigv)\\n- The reader doesn\\\'t handle equilibrium iteration files (d3iter)\\n- The reader doesn\\\'t handle extra time data files (d3xtf)\\n- The reader doesn\\\'t handle printer files (d3hsp)\\n- The reader doesn\\\'t handle modal neutral files (d3mnf)\\n- The reader doesn\\\'t handle packed connectivity.\\n- The reader doesn\\\'t handle adapted element parent lists (but the\\n 2002 specification says LSDyna doesn\\\'t implement it).\\n- All the sample datasets have MATTYP = 0. Need something to test\\n MATTYP = 1.\\n- I have no test datasets with rigid body and/or road surfaces, so\\n the implementation is half-baked.\\n- It\\\'s unclear how some of the data should be presented. Although\\n blindly tacking the numbers into a large chuck of cell data is\\n better than nothing, some attributes (e.g., forces & moments) lend\\n themselves to more elaborate presentation. Also, shell and thick\\n shell elements have stresses that belong to a particular side of an\\nelement or have a finite thickness that could be rendered. Finally,\\n beam elements have cross sections that could be rendered. Some of\\n these operations require numerical processing of the results and so\\nwe shouldn\\\'t eliminate the ability to get at the raw simulation data.\\n Perhaps a filter could be applied to "fancify" the geometry.\\n\\n\'})' __vtkname__ = 'vtkPLSDynaReader' # variables with complex values __loader__ = None # (!) real value is '<_frozen_importlib_external.ExtensionFileLoader object at 0x0000017F04E1BC50>' __spec__ = None # (!) real value is "ModuleSpec(name='vtkmodules.vtkIOParallelLSDyna', loader=<_frozen_importlib_external.ExtensionFileLoader object at 0x0000017F04E1BC50>, origin='C:\\\\Users\\\\xukai\\\\Downloads\\\\??2\\\\venv\\\\Lib\\\\site-packages\\\\vtkmodules\\\\vtkIOParallelLSDyna.cp311-win_amd64.pyd')"