search

GEGlobalResearch / DARPA-ASKE-TA1

ANSWER Project to demonstrate knowledge-driven extraction of scientific models from code and texts
Other
7 stars 5 forks source link

Create release compatible with SADL 3.5.0 #133

Open crapo opened 3 years ago

crapo commented 3 years ago

@AbhaMoitra , created GE ASKE release 1.1.0 compatible with SADL 3.5.0 and pushed as pre-release to github.com.

@tuxji , there is one error which doesn't appear to prevent the release from working but I'm stymied by it so if you have ideas I'd appreciate it.

  1. I have an error in line 27 of com.ge.research.sadl.darpa.aske.dialog/pom.xml: Could not load class: "com.ge.research.sadl.processing.IModelProcessor (eu.somatik.serviceloader-maven-plugin:serviceloader-maven- plugin:1.1.0:generate:default:compile)". Do you have such an error on Windows?
  2. Note that the project MANIFEST.MF has under "Import-Package" "com.ge.research.sadl.processing" and there is no error.
  3. Note also that project "com.ge.research.sadl", which contains "com.ge.research.sadl.processing.IModelProcessor", has in its MANIFEST.MF file under "Export-Package" "com.ge.research.sadl.processing" So I'm at a loss as to why the class could not be loaded. Thoughts?
tuxji commented 3 years ago

@crapo I don't get any error message about IModelProcessor on Ubuntu 20.04 with Java 11 running under WSL2 on Windows 10. My build completed successfully without any error messages. I did have to use the command `mvn clean package -DskipTests" because I was getting HTTP 404 Not Found errors in some of the tests. I assume these tests were trying to reach GRC servers and I was building at home without VPN access to GRC servers.

AbhaMoitra commented 3 years ago

@crapo : thank you for the updated release. I have installed it and I tried out one of the "dialogs"; it did some processing including building and executing KChain. But in doing sensitivity analysis, the service call failed. Sometimes the services are not running so it may be die to that. I tried it on another simpler dialog and it worked properly.

AbhaMoitra commented 3 years ago

@crapo : some more info. The fig below shows what I ran just now in previous version of ASKE. (Not sure what the red line in the console means.)

image

I ran the same dialog with the updated SADL and ASKE and here are 2 figures showing the results. Not sure why the output is going to console and the second figure scrolls down in the console to show the errors.

image

image

I believe I am using the same settings for the 2 runs but just in case I am capturing them here. The first one below is for the first run above (that ran fine).

image

and now the second dialog settings

image

crapo commented 3 years ago

@tuxji , yes, I did build with skipTests as I cannot reach the required services at GRC and have not installed them locally.

crapo commented 3 years ago

@AbhaMoitra , some observations.

  1. The message in red to the console window (with the old version if I understand correctly) indicates that a message from the back-end agent to the Dialog UI referenced a parse tree element (EObject) that was not found. This should not happen and indicates a failure of some kind in the human/agent conversation management.
  2. The JSON output in the console window for the new release would presumably be because the "debugMode" flag is true in the JenaBasedDialogInferenceProcessor code and when the previous release was built it was false. This should not have any effect other than the output to the console.
  3. Failure of the sensitivity analysis would prevent results from displaying in the dialog window, so it seems that this failure is the real crux of the problem. The service failing is the Invizin Service, the last host and port in the preferences. Did you have this failure and then immediately rerun the old version and it succeeded? If so then the question is why did the service call fail? If you can repeatedly have it succeed with old and fail with new, then we can conclude that the service requests are different. I can easily add a debug line to output the JSON sent to the service in the console. But that will not help you compare with the older version as you will not have that information for comparison. The easiest way to get more and adequate information is to look at the Invizin service logs (if there are such). Since the service reportedly failed but did connect the service logs should tell the story, showing the inputs in both the succeeding and the failing cases. Adding the debug statement would give the request string for the failing case and then Nurali or maybe Alfredo could perhaps look at it and identify what is wrong and that might lead to a solution.

Note that I do not have the various services running locally so I cannot easily debug. Nor am I familiar with the Invizin sensitivity service. Nurali implemented this.

AbhaMoitra commented 3 years ago

@crapo . Thanks. Here are my comments on your points.

  1. thanks - I am not very familiar with the ASKE code so would need to ask @agabaldon about it.
  2. is there a way to turn off "debugMode" - this is minor question.
  3. Initially I attributed the error in the new version to some service being down. But then I re-ran the older version and it ran so I would conclude that Invizin Service is not the issue; it is something else. Yes, this will also need to be looked at by @agabaldon or @iiternalfire .

I am actually not interested in the bulk of the code related to ASKE but I am testing it to try and keep it working. Thanks!

crapo commented 3 years ago

@AbhaMoitra , WRT #2, right now the flag is hardwired in the code. It is easily turned off by changing code and rebuilding the update. For right now it might be useful to have it on and to add the debug output of the Invizin service request for Nurali or Alfredo to look at.