Jump to content

Mr. Arne Bergmann

Members
  • Content Count

    156
  • Joined

  • Last visited

Posts posted by Mr. Arne Bergmann


  1. Hi Klaus,

     

    Please try to change the code of the function to the following:

    function quadrantCorrection(FPoint startp, FDouble phi):FDouble
      if (AND(startp.getY()>=0,startp.getX()<0)) // 2th. Q.
        phi = 180-#phi
      elseif (AND(startp.getY()>=0,startp.getX()>=0)) // 1st Q.
        phi = phi
      elseif (AND(startp.getY()<0,startp.getX()>=0)) // 4nd. Q.
        echo("Q4, phi " + phi)
        phi = 360-#phi
        echo("Q4, phiCorr " + phi)
      elseif (AND(startp.getY()<0,startp.getX()<0)) // 3rd. Q.
        phi = 180+#phi
      endif
      return(phi)
    endfunction
    

    It works for me like that. Apparently, there is a problem when trying to assign an expression to an argument inside a function that includes the argument itself. To be honest, I am not quite sure at the moment, why that is the case, but the '#' (detach) helps here.

     

    As an addition: Note that your function does not really need to return anything, since it just returns the argument. As opposed to other places, even basic types are passed to functions as references. So, when calling the function above like this:

    double d()
    point p()
    // .... initialize....
    quadrantCorrection(p, d)
    
    

    the variable d might have a different value after the call (except if the 1st Q case occurred). If you want to make sure that this does not happen, introduce a temporary variable (which, by the way, also takes away the need to use the detach):

    function quadrantCorrection(FPoint startp, FDouble phi):FDouble
      double result(phi)
      if (AND(startp.getY()>=0,startp.getX()<0)) // 2th. Q.
        result= 180-result
      elseif (AND(startp.getY()>=0,startp.getX()>=0)) // 1st Q.
        result = result
      elseif (AND(startp.getY()<0,startp.getX()>=0)) // 4nd. Q.
        echo("Q4, phi " + result)
        result= 360-result
        echo("Q4, phiCorr " + result)
      elseif (AND(startp.getY()<0,startp.getX()<0)) // 3rd. Q.
        phi = 180+result
      endif
      return(result)
    endfunction
    

    I hope this helps.

     

    Cheers,

    Arne


  2. Hi,

     

    In order to make sure that two connectors run in a fixed order, the second one (in your case fluent) needs to be dependent on the first one. Please see the second to last post in this thread: https://www.caeses.com/forum/index.php?/topic/303-connection-with-cfast/ for how to accomplish that.

     

    1) From what I can tell on your screenshots, I think you have got the name of the table in the parameter wrong. I think it needs to be "cd-1-history" instead of "cd1history" (since I have no result files, I cannot really test it).

     

    2) Actually, being able to calculate multiple designs at a time is a functionality of CAESES, so it behaves as it is supposed to. In general, if you want to make sure that only one computation runs at a time, it is the most efficient to disable "asynchronous" update for all your computations (in your project the computation "Runner" is set to asynchronous update).

     

    I hope this helps,

     

    Arne


  3. Hi Bodo,

     

    Apologies, but yes this is missing by accident and has already been identified. It will be included in the next release (along with doubleseries, unsignedseries and vector3series) as well as a more convenient way to fill those serieses in feature code by using the same syntax as for objectlists. Currently in order to create an integerseries inside the feature you'd have to write:

    fintegerseries myseries(integerseries(1,2,3,4,5))
    

    with the next release you can write

    integerseries myseries([1,2,3,4,5])
    

    So until the next release you will have to resort to using objectlists as arguments.

     

    Regards,

    Arne


  4. Hi,

     

    The Sobol supports parallel evaluation of multiple designs. This means, that it creates a variant, starts the external program(s) and continues to the next design. Once an external program finishes, the results are evaluated for that design. This allows to save time by running multiple evaluations at once.

    If you want to run only one external program at a time, you can disable the "asynchronous update" option of the computation. If you want to limit the number of running external processes (e.g. for license or CPU reasons), you can set that number at the Local Application that is used by the computation.

     

    Best regards,

    Arne


  5. Hi Bardo!

     

    Short answer: Please don't!

     

    Long answer: Yes, it is possible. And for transient I have to revoke my short answer, because for transient use it is OK. The basic way to do that is to pass the object you want to change as an argument to the Feature. You are then (currently) free to do whatever you want to that object inside the Feature. Note, though, that the argument-type has to match the object-type and cannot be a type the argument can be converted to (i.e. to change an FParameter, use FParameter not FDouble; for F3DPoint do not use FVector3, but F3DPoint - it would be fine to use an FPoint argument-type for F3DPoint, too, but then you could only change the FPoint part of the F3DPoint, or would need to use a cast). 

     

    For instances of Features (i.e. persistent Features) this is very problematic, though. The problem is that doing it breaks the dependency model that lies within every CAESES model. Features depend on their arguments (i.e. they are clients of the arguments). So whenever an argument changes, the Feature notices that it needs to be updated. Now, when the Feature itself changes such an argument, it actually causes the argument to become dependent of the Feature. This basically causes a recursive dependency model. I hope that it's clear that this is not good (the only reason it does not lead to disaster is because we built a safety net into Features especially for that case). In fact, it is not good on such a level, that the possibility to do something like that in a persistent Feature will be removed in the version that will hopefully be the next major release (for a very long answer, read the "Multithreading" entry of my blog - see link in my signature).

     

    tl;dr; you can do it by passing the object as an argument to the Feature, but please refrain from doing so for persistent Features as it will break the dependency model and will be illegal in future versions.

     

    Arne


  6. Hi Bodo,

     

    To be honest, I do not know why this fails in your specific case, but in general, this should work. The following feature works for me (FFeature::one creates a single point "p" - see also the attached project):

    // pre: FEntityGroup grp with instances of the other feature
    
    // iterate through all feature instances in the group using foreach
    foreach (FFeature::one f in grp)
      echo("" + f.getp().getx())  
    endfor
    
    // iterate through all feature instances in the group using while (omitting NULL check if the cast succeeds)
    unsigned i(0)
    double sum(0)
    while (i < grp.getCount())
      sum += grp.at(i).castTo(FFeature::one).getp().getx()
      i += 1
    endwhile
     echo("" + sum)  
     
    
    

    So, in general, your approach is the right one.

     

    Arne

    test.fdb


  7. Here's a little update including some new functionality that came with 4.0.

     

    post-7-0-44709200-1439214399_thumb.png

     

    In order to make the connection of your custom export feature to the Software Connector easier, it is now possible to use an "Export Feature Definition" directly in the Software Connector. After adding a new "Input Geometry" item (top-left pane of the Software Connector; no. 1 in the screenshot above), it is now possible to choose "FeatureDefinition" as the "Source" (2 in the screenshot). After selecting it, you will be able to select one of the feature definitions from your project that do one of the following:

    • Write a file (i.e. use one of the "write" commands of FFile, including "openWrite")
    • Use an FExportCmd (e.g. FTrimesh.exportSTL())
    • Use one of the FExport objects (e.g. FExportStep)

    After selecting a feature definition that does one of the above (3 in the screenshot), its arguments can be filled directly in the object editor of the SoftwareConnector entry (4 in the screenshot).

    After doing so, the selected feature definition will be executed just like a regular export when the Software Connector runs.

     

    So, it is no longer needed to "connect" an instance of the feature definition with an entry of the Software Connector or to make sure that the feature goes out of date when a new design is created (see post above)!

     

    Also, when writing files using the FFile type, it is now possible to just use a relative path (e.g. a file name only) in the export feature. If that is done, the file will automagically be written into the computation's input directory! So you do not have to worry about resolving the correct directory when writing your custom exports.

     

    I think this makes exporting custom file formats through features a lot easier and way more convenient, so I hope you like it.

     

    See the attached project to see a version of the project in the first post as it would be set-up in 4.0. The only two places to look at are the FeatureDefinition itself (which has not changed, except that it does not take the path to export to as an argument anymore, because it uses the file name only) and the "ExportAPF" entry of the software connector.

    featureExport.fdb


  8. Hi Henrik,

     

    Ok, I understand. Since your SSH scripting runs as a local process (i.e. the ssh executable) the local limit is the limit. CAESES doesn't know that the actual CFD will run remotely.

    Since we activated the SshResourceManager for your licenses, there is no limitation for the setting "maximum number of local processes". You will have to start CAESES with the command line argument "-forcecheck" (on Windows there is a start menu entry "force license check") in order to get the updated license.

     

    Best regards,

    Arne


  9. Oh, I forgot to mention: In case you want to trigger multiple StarCCM+ runs within your scripts, this would be possible, too. Let's say you want to trigger N runs with N sets of Variable values, you would need to repeat this section N times:

    // all designs should be created from the baseline, so your tree doesn't get too deep
    baseline.edit()
    
    design(NULL, NULL)
    
    // set variables here myDeva.setValue(...)
    
    starComputation.run()
    

    However, in that case you would need to manually change into every design that was created after your "DesignEngine" run has finished, in order to get CAESES to read the Star-CCM+ results for post-processing. This could be automated, too, with an fsc script, but not in a way that will work the same every time:

    When creating your designs (design(NULL, NULL)), you can also provide a design name, e.g.:

    design design1(NULL, NULL)
    

    In your generated scripts, the number should be increased for every design, in order to create unique names. Then you need to keep track of how many designs you created. Then the final script would look something like this:

    design1.edit()
    design2.edit()
    design3.edit()
    
    // ...
    
    designN.edit()
    
    saveProject()
    //DONE
    

    Note that I added the "saveProject()", just to be sure  ;)

     

    I said that this would not work the same every time, because CAESES may alter the names of the designs, if an object with the same name already exists in the project. So you can only be sure that the designs will have the names you chose, when you ensure beforehand that no objects with the same name exist. This means running this "DesignEngine" multiple times within the same project which is saved in between, the second run will not update the correct designs at the end. So each "DesignEngine" run needs to start from a "clean" version of the project.

     

    Best regards,

    Arne


  10. Hi Henrik,

     

    Actually, CAESES does not include an interface that allows to "remote control" it. Also, I do not really have any previous experience with Heeds. However, there are ways to achieve what you want, but they are not really straight forward.

     

    I think the best option is to use fsc-scripts along with the "waitAndExecScript(FString filename, FInteger timeout)" command. This (undocumented) command waits until the given filename exists and the content of the file ends with the line "//DONE". As soon as that is the case, the file is executed as an fsc-script. The second parameter tells CAESES how long it should wait for the file in seconds before giving up (a value of -1 means forever).

     

    With this in mind, you could maybe write a bash script or little program in your favorite programming language that writes an fsc-script based on the output of Heeds (or maybe Heeds can do it itself? As I said, I do not have experience with it.) After that the process could be as follows (rough outline, to give you an idea):

    • Start CAESES from within Heeds with an initial fsc script which would look like this: 
      openProject("path/to/your/project")
      
      // here you could set the initial values of your design variables, e.g. myDeva.setValue(0.1)
      
      // create a new design
      design(NULL,NULL)
      
      // trigger StarCCM+
      starComputation.run()
      
      // tell CAESES to wait for a script file to appear in the results directory
      waitAndExecScript(getResultsDir() + "/continue.fsc")
      
    • Now Heeds would have to analyze the StarCCM+ output and create the new values for the design variables (those of interest). Then the next script should be generated in the same directory as the StarCCM+ result files. This could look like this: 

      // go back to the baseline
      baseline.edit()
      
      // create next design
      design(NULL, NULL)
      
      // set the designvars you want here (based on Heeds)
      myDeva1.setValue(...)
      myDeva2.setValue(...)
      // ....
      
      starComputation.run()
      
      // now wait for the next script
      waitAndExecScript(getResultsDir() + "/continue.fsc")
      
      // trigger the previous waiting to end
      //DONE
      
    • Once the "DesignEngine" is done, the new script would just need include the "//DONE" line at the end (maybe change back into the baseline, too)

    As I said, this is the rough outline of the process, I have in mind. You will need to fill in the details since I do not know Heeds.

     

    I hope this helps and gives you an idea, how you can do the coupling.

     

    Best regards,

    Arne


  11. Dear Henrik,

     

    Do you mean the number of processes through the SshResourceManager? The student license normally does not include the full SshResourceManager. This means you can use it, but only one remote job can be started from within CAESES at a time.

    We have activated the full SshResourceManager now for both of your licenses. The job limited can be configured in the SshResourceManager's configuration file. It is defaulted to 100 simultaneous jobs.

    The local limit does not influence the remote limit.

     

    Best regards,

    Arne


  12. Hi Oliver,

     

    since the Feature Language doesn't have the concept of scoping known from C or Java (or others). So, in short, it doesn't really matter whether you declare the FCurve reference "camber" inside or outside the loop. These two are equivalent:

    bsplinecurve myCurve()
    FCurve myReference()
    
    loop(1)
      FCurve myReference(myCurve)
    endloop
    
    // The reference is still valid here, so I can do the following, for example:
    myReference.getPos(0.5)
    // which is equivalent to calling ".getPos(0.5)" on "myCurve"
    

    and

    bsplinecurve myCurve()
    
    loop(1)
     FCurve myReference(myCurve)
    endloop
    
    // The reference is still valid here, so I can do the following, for example:
    myReference.getPos(0.5)
    // which is equivalent to calling ".getPos(0.5)" on "myCurve"
    

    Note that most types in the Feature Language do not have assignment operators ("=").

     

    Also note that the Syntax "FCurve something([...])" creates a reference to an existing curve. it does not create a new curve! Also see the documentation of FFeatureDefinition for more information about references.

     

    Be aware that in your example, the "camber" reference will reference the last (fifth) curve in your objectlist after the loop. Inside the loop it will reference different curves for each run of the loop.

     

    Finally, while my initial statement regarding variable scoping is true, there is one little exception: variables that are declared inside a function are only valid within the function.

     

    I hope this helps.

     

    Arne


  13. Hi Britt,

     

    To be honest, we just tried it on a 4K 60 inch Philips TV and could not produce any problems (see attached photos - note that one of them was done with the upcoming 4.0 version, but the other two are with the current 3.1.4 release). We had it running on a Nvidia GTX 760 graphics card.

     

    From your screenshot it looks like you have used the "Zoom In" functionality of CAESES, so we played around with that, too, but it never looked wrong.

     

    So it seems like it's a problem of your particular hardware, to be honest.

     

    Best regards,

    Arne

     

    post-7-0-05966500-1435240431_thumb.jpg

    post-7-0-68663400-1435240441_thumb.jpg

    post-7-0-96147200-1435240455_thumb.jpg


  14. Hi Graeme,

     

    Glad that it worked.

     

    For a comparison of CAESES free vs the commercial version, please see the chart on this page: https://www.caeses.com/products/caeses-free/

     

    You can get a free two weeks trial license for the full version by selecting "License Upgrade" from the "Help" menu and selecting "Non-commercial Trial License Registration".

     

    If you are interested in a quotation for the full version, please send an email to sales@friendship-systems.com

     

    Best regards,

    Arne


  15. Hi Graeme,

    Our license expert is already looking into this.

     

    Here's another thing you can try:
    Search your computer for the file "FS_LICENSE_SHM2" (it's probably located in the path "C:\ProgramData\boost_interprocess") and delete that file manually. After that try to start CAESES again.

     

    Best regards,

    Arne


  16. Dear Graeme,

     

    Currently we do not experience any problems with the license server.

     

    Regarding the start-up problem, please try to manually reset CAESES to factory settings. Please open a windows explorer (Win-Key + E) and enter

    %APPDATA%/friendship/etc

    into the address bar. Delete all files in that directory. Then try to start CAESES again.

     

    Best regards,

    Arne

    • Upvote 1
×
×
  • Create New...