AWS EC2 instance of Openstudio-server

openstudio-server

asked 2017-05-04 23:53:04 -0600

Chienman
588 ●6

updated 2017-05-04 23:58:34 -0600

I've never had an issue launching a new instance of the Openstudio-server. For some reason though, the latest instance seems to be configured differently.

See the attached screenshots. The workers are look like they are throwing errors, and eventually the simulations start looking funny. For example, the delta time is negative? I am using the latest dockerize branches. Not sure if anyone is experiencing similar issues.

C:\fakepath\Console output.tiff

C:\fakepath\Simulation Results.tiff

Any subsequent set of simulations I launch, seem to hang in a "queue" mode. It is almost like the workers aren't being deployed by the server.

C:\fakepath\Queuing Only.tiff

edit retag flag offensive close merge delete

Comments

I have seen this behavior recently also. Just for comparison, which OS Server version are you using? I am still using an "older" one: 1.21.16.

__AmirRoth__ ( 2017-05-05 09:12:22 -0600 )edit

Hi-

That is a great question! My dockerfile simply states "latest" as in

nrel/openstudio-server:latest

You're right, I should try rolling back to an earlier version if I can find one on the dockerhub. Good call.

But no real luck there, the oldest image on there is "latest" :\

Chienman ( 2017-05-05 09:39:39 -0600 )edit

i'm a little confused, you are using your own docker containers and not AWS, right? The messages in the worker are not concerning, just a bunch of warnings. I bet your issue lies in the reporting or outputs section. make sure the objective functions are typed in correctly as far as measure name and variable name goes. also that the measure is 2.0 compatible.

BrianLBall ( 2017-05-05 10:19:25 -0600 )edit

I am using AWS actually. I had an old AWS instance that was about a month old. Yesterday, it started acting funny. So I used docker-machine stop <machine name> and docker-machine rm <machine name> . I've been informed I was supposed to delete my volume before I did this, which I have not been doing.

Unfortunately, once you've removed with the docker-machine command, the volume is no longer visible. So I don't know if it exists somewhere. I'm trying to work this out.

@BrianLBall what is odd is that I have been using the EXACT same spreadsheets as before, and had success.

Chienman ( 2017-05-05 10:27:00 -0600 )edit

okay, so you are provisioning your own AWS instance. neat. yeah, you might want to do the following to clear out the volume: docker volume ls docker volume rm xxx docker volume create --name=osdata docker-compose up &

click on the datapoint json link for the completed ones. i bet you will some message in there about objective functions not being found. verify that the measure.variable name is consistent with whats in the analysis.json

BrianLBall ( 2017-05-05 10:31:17 -0600 )edit

@BrianLBall where can I read more about compatibility? How do I know if the measure is 2.0 compatible?

Chienman ( 2017-05-05 10:53:58 -0600 )edit

add a comment

answered 2017-05-05 11:26:06 -0600

Chienman
588 ●6

I get to answer my own question. The reason I am seeing this happen is because I did not remove the volume before creating it again. It would be great if someone like @nllong could explain why this has to be done, but the basic gist of it for a lay person is that once a volume named osdata has been created a first time, it subsequently has to be removed before being recreated for new instances. (this feels a little like phlogiston reasoning, I'm sure it is not quite right).

To solve this problem, you have two options:

change the name of the volume in your compose file and and all references to the volume in other files. This is a bit hard to do and is tedious. Lots of places. I had to make changes in docker-compose.deploy.up and circle.yml.
do the following:

docker-compose rm -f docker volume rm osdata docker volume create --name=osdata docker-compose up

That extra step to rm osdata is a clean up step. Either way, now my server on AWS is back in business! Thanks to Ry Horsey I think that is @rhorsey for helping me through this.