SALOME. Nevertheless, it is possible for low-weight deployment to
install only the MEDMEM library from the source files embedded in the
SALOME FIELDS module. Keep in mind that the MEDMEM library is designed to
-be a self-consistent library with very few third party softwares (only
+be a self-consistent library with very few third party software (only
med-file, glibc and mpi typically). In particular, it is strictly
independent from the SALOME framework even if it distributed with
SALOME for convenience reasons.
* ``medcalc.MakeVectorField``
-.. LocalWords: softwares
+.. LocalWords: software
result = p3+p4
result.setName("p3+p4")
-# We can finally save the result together with the operandes fields
+# We can finally save the result together with the operands fields
outfilename = "addition.med"
MEDLoader.WriteField(outfilename,result,True)
MEDLoader.WriteField(outfilename,p3,False)
typedef sequence<MeshHandler> MeshHandlerList;
/**
- * The Fieldseries is a virtal object that does not exist in the MED
+ * The Fieldseries is a virtual object that does not exist in the MED
* data model (at least in the MEDCoupling data model). It is just a
- * point that aggregate a list of fields that relie on the same mesh
+ * point that aggregates a list of fields that rely on the same mesh
* with the same type (the fields in a timeseries differ by their
* time step).
*
* Then you could have a field with no fieldseries associated but
* directly associated to a mesh. That is typically the case of
- * fields created by MED operations: if you operate tow fields
+ * fields created by MED operations: if you operate two fields
* coming from 2 different timeseries (and relying on the same
- * mesh), you obtain a field that can not be associate to the
+ * mesh), you obtain a field that can not be associated to the
* original timeseries. Then this new created field must be directly
* associated to its underlying mesh (as defined in the MEDCoupling
* data model).
MEDCALC::FieldHandler * MEDCalculator_i::add(const MEDCALC::FieldHandler & f1_hdl,
const MEDCALC::FieldHandler & f2_hdl)
{
- // We first check that both operandes share the same mesh id. Note
+ // We first check that both operands share the same mesh id. Note
// that it's not strictly required because the MEDCoupling operation
// would raise an exception if the fields does not share the same
// mesh support.
if ( f1_hdl.meshid != f2_hdl.meshid ) {
std::string message =
- std::string("ERROR: Mesh ids are different for the field operandes ") +
+ std::string("ERROR: Mesh ids are different for the field operands ") +
std::string(f1_hdl.fieldname) + std::string(" and ") + std::string(f2_hdl.fieldname);
throw KERNEL::createSalomeException(message.c_str());
}
// >>>>>>>>>
// _GBO_ We should test here if the iteration and order of the input
- // files are identical for both operandes. A convention has to be
+ // files are identical for both operands. A convention has to be
// defined here. By default, we let the iteration and order be
// determined by the resulting MEDCouplingFieldDouble instance (see
// function addField of the data manager).
{
if ( f1_hdl.meshid != f2_hdl.meshid ) {
std::string message =
- std::string("ERROR: Mesh ids are different for the field operandes ") +
+ std::string("ERROR: Mesh ids are different for the field operands ") +
std::string(f1_hdl.fieldname) + std::string(" and ") + std::string(f2_hdl.fieldname);
throw KERNEL::createSalomeException(message.c_str());
}
{
if ( f1_hdl.meshid != f2_hdl.meshid ) {
std::string message =
- std::string("ERROR: Mesh ids are different for the field operandes ") +
+ std::string("ERROR: Mesh ids are different for the field operands ") +
std::string(f1_hdl.fieldname) + std::string(" and ") + std::string(f2_hdl.fieldname);
throw KERNEL::createSalomeException(message.c_str());
}
{
if ( f1_hdl.meshid != f2_hdl.meshid ) {
std::string message =
- std::string("ERROR: Mesh ids are different for the field operandes ") +
+ std::string("ERROR: Mesh ids are different for the field operands ") +
std::string(f1_hdl.fieldname) + std::string(" and ") + std::string(f2_hdl.fieldname);
throw KERNEL::createSalomeException(message.c_str());
}
Main entry point is test_qttesting.py.
Each scenario is described in a XML file and can be recorded directly in the GUI via the "Record test" button.
-A scneario must save a final screenshot of the ParaView view in a file located in the temp directory (TODO: review
+A scenario must save a final screenshot of the ParaView view in a file located in the temp directory (TODO: review
this). This file is compared against a baseline saved in the baselines subdirectory.
MEDCoupling::MEDCouplingCurveLinearMesh *targetMesh=MEDCoupling::MEDCouplingCurveLinearMesh::New();
targetMesh->setTime(2.3,4,5);
targetMesh->setTimeUnit("us");
- targetMesh->setName("Example of Cuve linear mesh");
+ targetMesh->setName("Example of Curve linear mesh");
targetMesh->setDescription("buildCLMesh");
MEDCoupling::DataArrayDouble *a1=MEDCoupling::DataArrayDouble::New();
a1->alloc(3*20,1);
targetMesh=MEDCouplingCurveLinearMesh();
targetMesh.setTime(2.3,4,5);
targetMesh.setTimeUnit("us");
- targetMesh.setName("Example of Cuve linear mesh");
+ targetMesh.setName("Example of Curve linear mesh");
targetMesh.setDescription("buildCLMesh");
a1=DataArrayDouble(3*20,1);
a1.iota(7.) ; a1.rearrange(3);
